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1.0  Introduction 


1.1  Joint  Advanced  Distributed  Simulation  Overview 

The  Joint  Advanced  Distributed  Simulation  Joint  Test  and  Evaluation  (JADS  JT&E)  was  chartered  by 
the  Deputy  Director,  Test,  Systems  Engineering  and  Evaluation  (Test  and  Evaluation),  Office  of  the 
Under  Secretary  of  Defense  (Acquisition  and  Technology)  in  October  1994  to  investigate  the  utility  of 
advanced  distributed  simulation  (ADS)  technologies  for  support  of  developmental  test  and  evaluation 
(DT&E)  and  operational  test  and  evaluation  (OT&E).  The  program  is  Air  Force  led,  with  Army  and 
Navy  participation.  The  Joint  Test  Force  (JTF)  manning  includes  23  Air  Force,  13  Army,  and  2  Navy. 
Science  Applications  International  Corporation  and  Georgia  Tech  Research  Institute  provide  contracted 
technical  support.  The  program  is  nominally  scheduled  for  five  years. 

The  JADS  JT&E  charter  focuses  the  evaluation  of  utility  on  three  issues:  (1)  What  is  tire  present  utility 
of  ADS,  including  distributed  interactive  simulation  (DIS),  for  T&E?  (2)  What  are  the  critical 
constraints,  concerns,  and  methodologies  when  using  ADS  for  T&E?  (3)  What  are  the  requirements 
that  must  be  introduced  into  ADS  systems  if  they  are  to  support  a  more  complete  T&E  capability  in  the 
future.  From  these  issues,  objectives  and  measures  have  been  developed  to  guide  the  evaluation. 

The  JADS  JT&E  is  directly  investigating  ADS  applications  in  three  slices  of  the  T&E  spectrum:  a 
System  Integration  Test  (SIT)  which  explores  ADS  support  of  air-to-air  missile  testing,  an  End-To-End 
(ETE)  Test  which  explores  ADS  support  for  command,  control,  communications,  computers,  and 
intelligence,  surveillance  and  reconnaissance  (C4ISR)  testing,  and  an  Electronic  Warfare  (EW)  Test 
which  explores  ADS  support  for  EW  testing.  Each  test  will  apply  the  JADS  objectives  and  measures 
as  appropriate  to  conduct  their  evaluation.  The  JTF  is  also  chartered  to  observe,  or  participate  at  a 
modest  level,  in  ADS  activities  sponsored  and  conducted  by  other  agencies  in  an  effort  to  broaden 
conclusions  developed  in  the  three  dedicated  test  areas. 

The  JADS  ETE  Test  is  the  subject  of  this  report  and  is  described  in  the  next  section;  flie  following  is  a 
brief  synopsis  of  the  SIT  and  EW  tests. 

The  SIT  evaluated  the  utility  of  using  ADS  to  support  cost-effective  testing  of  an  integrated  missile 
weapon/launch  aircraft  system  in  an  operationally  realistic  scenario.  The  SIT  also  evaluated  the 
capability  of  the  JADS  Test  Control  and  Analysis  Center  (TCAC)  to  control  a  distributed  test  of  this 
type  and  to  remotely  monitor  and  analyze  test  results.  The  SIT  consisted  of  two  phases,  each  of  which 
culminated  in  three  flight  missions.  The  missions  simulated  a  single  shooter  aircraft  launching  an  air-to- 
air  missile  against  a  single  target  aircraft.  In  the  Linked  Simulators  Phase  (LSP),  the  shooter,  target,  and 
missile  were  all  represented  by  simulators.  In  the  Live  Fly  Phase  (LFP),  the  shooter  and  target  were 
represented  by  live  aircraft  and  the  missile  by  a  simrdator. 

The  EW  test  will  evaluate  the  utility  of  ADS  in  a  distributed  EW  test  environment.  The  first  phase  is 
open  air  testing  to  develop  a  performance  baseline  for  two  subsequent  test  phases.  The  first  distributed 
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test  phase  employs  a  linked  architecture  utilizing  Department  of  Defense’s  (DoD)  high  level  architecture 
(HLA)  which  includes  a  digital  simulation  model  of  the  ALQ-131  self-protection  jammer,  threat 
simulation  facilities,  and  constmctive  models  which  support  replication  of  the  open  air  environment.  In 
the  second  phase,  an  installed  systems  test  facility  is  substituted  for  the  digital  model.  In  both  distributed 
test  architectures,  system  performance  data  will  be  compared  with  live  fly  data  for  verification  and 
validation  (V&V). 

1.2  Test  Overview 

The  ETE  test  is  designed  to  evaluate  the  utility  of  ADS  to  support  testing  of  C4ISR  systems.  The  test 
will  use  the  developmental  and  operational  testing  issues  for  the  Joint  Surveillance  Target  Attack  Radar 
System  (Joint  STARS)  to  conduct  its  T&E  utility  evaluation  in  an  ADS-enhanced  test  environment. 
Additionally,  ETE  also  includes  an  evaluation  of  JADS  Test  Control  and  Analysis  Center’s  (TCAC) 
capabihty  to  control  a  distributed  test  of  this  type  and  remotely  monitor  and  analyze  test  results 

The  ETE  is  using  distributed  simulation  to  assemble  an  enhanced  environment  to  be  used  for  testing 
C4ISR  systems.  The  intent  is  to  provide  a  complete,  robust  set  of  interfaces  from  sensor  to  weapon 
system  including  the  additional  intermediate  nodes  that  would  be  found  in  a  tactical  engagement.  The 
test  will  trace  a  thread  of  the  complete  battlefield  process  fi’om  target  detection  to  target  assignment  and 
engagement  at  corps  level  using  ADS.  It  will  allow  the  tester  to  evaluate  the  thread  as  a  whole  or  the 
contribution  of  any  of  the  parts  individually  and  to  evaluate  what  effects  an  operationally  realistic 
environment  has  on  the  system  under  test. 

The  major  focus  of  the  ETE  is  the  evaluation  of  ADS  enhancements  to  the  testing  of  Joint  STARS.  A 
limitation  identified  in  the  Joint  STARS  multi-service  operational  test  and  evaluation  (MOT&E)  plan  was 
the  inability  to  test  Joint  STARS  ability  to  support  a  notional  corps  area  of  interest.  As  a  result  of  this 
limitation,  many  of  the  MOT&E  measures  were  or  will  be  collected  under  conditions  short  of  the 
projected  Joint  STARS  operational  environment. 

Thus,  the  ETE  is  designed  to  add  additional  entities  in  a  seamless  manner  to  the  battlefield  seen  by  the 
Joint  STARS.  In  addition,  adding  some  of  the  complementary  suite  of  other  C4I  and  weapon  systems 
with  which  Joint  STARS  would  interact  will  enable  the  test  team  to  evaluate  the  utility  of  an  ADS- 
enhanced  test  environment. 

The  test  concept  (Figure  1)  is  to  use  ADS  to  supplement  the  operational  environment  the  E-8C  and 
ground  station  module  (GSM)  operators  would  experience.  By  mixing  the  available  five  targets  with 
targets  generated  by  a  constructive  model,  a  battle  array  that  approximates  the  major  systems  present  in 
a  notional  corps  area  of  interest  can  be  presented.  Additionally,  by  constracting  a  network  with  nodes 
representing  appropriate  C4I  and  weapon  systems,  a  more  robust  cross  section  of  players  is  available 
with  which  the  E-8C  and  GSM  operators  can  interact. 
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ACE  -  analysis  and  control  element  ATACMS  -  Army  Tactical  Missile  System  SCDL  -  surveillance  control  data  link 

ASAS  -  All  Source  Analysis  System  FDC  -  fire  direction  center 


Figure  1.  ETE  Test  Concept 

Several  components  are  required  to  create  the  ADS-enhanced  operational  environment  that  will  be 
used  in  the  ETE.  In  addition  to  Joint  STARS,  the  ETE  will  require  a  validated  simulation  capable  of 
generating  entities  that  will  represent  the  elements  in  the  rear  of  a  threat  force.  Also,  simulations  of  the 
Joint  STARS  moving  target  indicator  (MTI)  radar  and  synthetic  aperture  radar  (SAR)  will  be  used  to 
insert  the  simulated  entities  into  the  radar  stream  aboard  the  E-8C  while  it  is  flying  a  live  mission.  Other 
capabilities  used  to  support  the  test  include  a  subset  of  the  Army’s  analysis  and  control  element  (ACE), 
simulations  or  subsets  of  the  Army’s  artillery  command  and  control  process,  and  a  simulation  of  the 
Army’s  Advanced  Tactical  Missile  System  (ATACMS).  Communications  among  these  simulations  will 
be  accomplished  using  doctrinally  correct  Advanced  Field  Artilleiy  Tactical  Data  System  (AFATDS) 
message  traffic  and  DIS  protocol  data  units  (PDU). 

The  ETE  test  consists  of  four  phases.  Phase  1  develops  or  modifies  the  components  that  allow  the  mix 
of  live  and  simulated  targets  at  an  E-8C  operator’s  console  and  ground  station  module  (GSM) 
operator’s  console.  Phase  2  evaluates  the  utility  of  ADS  to  support  DT&E  and  early  OT&E  of  a 
C4ISR  system  in  a  laboratory  environment.  Phase  3  transitions  portions  of  the  architecture  to  the  E-8C 
and  ensures  the  components  function  properly  and  the  synthetic  environment  interacts  with  the  aircraft 
and  the  actual  GSM  in  a  proper  maimer.  Phase  4  evaluates  the  ability  to  perform  test  and  evaluation  of 
the  E-8C  and  GSM  in  a  synthetically  enhanced  operational  environment  using  typical  operators. 
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2.0  Phase  1  Overview 


2.1  Phase  1  Purpose 

The  purpose  of  Phase  1  is  to  develop,  modify,  and  integrate  software  and  hardware  which  will  be  used 
to  establish  the  EXE  test  environment  as  well  as  plan  and  coordinate  activities  for  Phases  2  through  4. 

The  ETE  environment  components  developed  during  Phase  1  consist  of  a  constructive  simulation  to 
provide  virtual  targets,  an  E-8C  simulation  called  the  Virtual  Surveillance  Target  Attack  Radar  System 
(VSTARS),  an  interface  to  allow  surveillance  and  control  data  link  (SCDL)  traffic  from  VSTARS  to  be 
displayed  in  the  GSM,  and  an  ADS  network  suitable  for  integration  and  testing. 

2.2  Phase  1  Approach 

The  JADS  ETE  team  developed  requirements  for  a  constmctive  simulation  and  then  evaluated  available 
constructive  simulations  against  these  requirements.  The  Janus  simulation  developed  and  managed  by 
the  U.S.  Army  Training  and  Doctrine  Command  (TRADOC)  Analysis  Center,  White  Sands  Missile 
Range  (TRAC-WSMR),  New  Mexico,  was  selected  as  the  simulation  which  had  the  best  potential  of 
being  modified  to  meet  JADS  requirements.  TRAC-WSMR  expanded  the  Janus  scenario  driver  into 
Janus  6.88D,  a  constructive  simulation  capable  of  supporting  up  to  10,000  individual  entities  with  a 
distributed  interactive  simulation  (DIS)  interface  to  the  ETE  environment 

The  JADS  ETE  team  investigated  existing  simulations  of  Joint  STARS  and  determined  that  none  of  the 
existing  simulations  met  the  fidelity  requirements.  Northrop  Grumman,  the  developer  of  the  E-8C, 
performed  the  engineering  and  development  of  both  a  laboratory  emulation  of  the  E-8C  radar 
subsystem  and  the  capability  to  integrate  the  E-8C  into  a  synthetic  environment.  The  VSTARS  is  a 
laboratory  emulation  of  the  E-8C  radar  subsystem  and  other  aircraft  components  which  can  receive 
synthetic  targets  from  a  DIS  network  and  provide  the  stimulus  to  display  these  targets  on  the  Advanced 
Technology  Work  Station  (ATWS)  or  on  the  ground  station  module.  The  radar  processor  simulator 
and  integrator  (RPSI)  and  the  air  network  interface  unit  (ANIU)  are  the  portions  of  the  VSTARS  which 
are  installed  on  the  aircraft. 

One  of  the  more  challenging  aspects  of  Phase  1  was  developing  a  near  real-time  simulation  of  the  E-8C 
synthetic  aperture  radar  (SAR).  JADS  ETE,  through  the  Advanced  Research  Projects  Agency 
(ARPA)  War  Breaker  project,  conducted  a  trade  study  of  various  existing  simulations.  We  selected  the 
XPATCHES  simulation  developed  by  Wright  Laboratory  (Dayton,  Ohio)  and  Loral  Defense  Systems 
(Goodyear,  Arizona)  as  being  the  best  starting  point  for  the  E-8C  SAR  simulation.  Lockheed  Martin 
Tactical  Data  Systems,  Goodyear,  Arizona,  developed  a  SAR  simulation  that  emulates  the  Joint 
STARS  SAR  operation.  This  simulation  system  is  referred  to  as  the  Advanced  Radar  Imaging 
Emulation  System  (ARIES)  and  is  operationally  embedded  into  Northrop  Grumman’s  radar  processor 
simulation  and  integrator  RPSI. 
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The  normal  cxjimection  between  the  E-8C  and  its  associated  groimd  stations  is  through  a  line-of-sight 
data  link  called  the  surveillance  control  data  link  (SCDL).  After  considerable  investigation,  the  JADS 
EXE  team  determined  this  link  could  not  be  easily  transmitted  via  commercial  communications  lines. 
Based  on  discussions  among  the  team,  Northrop  Grumman,  and  Motorola,  we  determined  the  best 
approach  would  be  to  develop  interfaces  which  transferred  the  normal  message  traffic  between  the  E- 
8C  and  GSM  rather  than  attempting  to  transfer  the  SCDL  messages  directly.  Northrop  Grumman  and 
Motorola  developed  an  interface  control  document  which  defined  this  message  traffic.  Northrop 
Grumman  included  the  capability  in  VSTARS  to  capture  these  messages  and  divert  them  to  an  Ethernet, 
and  Motorola  developed  an  interface  unit  between  the  GSM  and  an  Ethernet.  This  interface  unit  links 
the  Ethernet  with  the  internal  1553  databus  of  the  GSM.  Additionally,  the  interface  unit  simulates  the 
operation  of  the  ground  data  terminal  forcing  the  GSM  operator  to  perform  the  normal  linking  process 
prior  to  receiving  the  message  traffic  from  VSTARS. 

Initially,  network  equipment  installed  in  Phase  1  coimected  TRAC-WSMR  with  the  JADS  TCAC  at 
Albuquerque,  New  Mexico,  and  then  extended  the  network  from  the  TCAC  to  the  Northrop  Grumman 
laboratory  facilities  at  Melbourne,  Florida.  Late  in  Phase  1,  this  network  was  extended  to  include  links 
from  the  TCAC  to  Fort  Hood,  Texas,  and  Fort  Sill,  Oklahoma,  and  a  link  between  Northrop  Grumman 
and  Fort  Hood. 

During  Phase  1,  the  JADS  team  evaluated  two  logger  capabilities  for  use  during  the  ETE  test.  One  of 
these  was  developed  in  support  of  Janus  and  the  other  is  a  product  from  the  U.S.  Army  Simulation, 
Training,  and  Instrumentation  Command.  The  primary  concern  was  to  evaluate  or  establish  the  ability  to 
accurately  log  large  numbers  of  protocol  data  units  (PDUs)  over  several  hours.  Several  shortcomings  of 
both  of  these  products  led  the  JADS  team  to  develop  the  JADS  logger.  The  JADS  team  also 
developed  a  set  of  data  reduction  and  analysis  tools  in  support  of  the  ETE  test. 

2.3  Phase  1  Schedule 

The  schedule  for  Phase  1  was  driven  by  the  availability  of  funding  and  by  contracting  delays.  Due  to 
funding  constraints  during  fiscal  year  (FY)  95,  the  ETE  test  was  limited  to  modification  of  Janus  and  to 
conducting  architecture  and  engineering  studies  on  the  Joint  STARS  simulation.  Initial  contracting  for 
the  studies  required  eight  months  and  actual  development  of  the  RPSI  and  ARIES  did  not  begin  until 
FY97.  Figure  2  is  the  as  built  schedule  for  Phase  1. 
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Figure  2.  Phase  1  Schedule 

2,4  Phase  1  Costs 

Table  1  outlines  the  costs  for  Phase  1. 


Table  1.  Phase  1  Costs 


Element  of  Cost 

Cost 

Total 

Janus  6.88D 

$462,000 

$462,000 

Janus  Hardware  Suite  (2) 

$80,000 

E-8C  Simulation 

$2,617,560 

Architecture/Engineering  Design 

$678,000 

Development/Integration 

$1,839,560 

Contracting  Fee 

$100,000 

ARIES  Development 

$864,450 

Development 

$832,830 

Contracting  Fee 

$31,620 

SCDL  Link  Development 

$327,490 

Network  Leases 

$90,312 

Network  Equipment  and  Instrumentation 

$173,720 

Test  Team  Expenses 

$114,360 

Hardware/Soflware 

$21,040 

Travel 

$85,530 

Training 

$7,790 

6 


Total  Phase  1  Costs 


$4,729,892 


3.0  Phase  1  Results 

3.1  Constraints,  Concerns,  and  Methodologies  When  Using  ADS 

One  of  the  key  constraints  identified  for  JADS  is  the  ability  of  the  DoD  infirastructure  to  support  ADS 
test  and  evaluation.  A  measure  of  this  constraint  is  found  in  the  amount  of  development  required  to 
establish  a  synthetic  environment  with  which  to  conduct  testing.  The  ETE  test  provides  insight  into  the 
amount  of  development  required  to  support  a  test  of  this  type  and  demonstrates  the  apphcation  of  a 
systems  engineering  methodology  to  identify  the  requirements  for  ADS  components,  evaluate  the 
availability  of  ADS  components,  and  modify  or  develop  the  components  to  meet  the  requirements. 

3.1.1  Constructive  Simulation  -  Janus  6.88D 

To  generate  the  notional  corps  rear  area,  a  constmctive,  entity-level  simulation  was  required.  The 
following  represents  the  requirements  developed  to  evaluate  the  capabihty  of  various  existing  simulations 
to  support  the  JADS  ETE. 

Requirements: 

•  Capable  of  simulating,  or  of  being  modified  to  simulate,  at  least  5000  distinct  entities  with  at  least 
twenty-five  percent  moviag  in  a  reasonable  and  affordable  manner. 

•  Capable  of  issuing  DIS  2.0.4  entity  state  (ES)  PDUs  that  describe  each  entity  simulated. 

•  Capable  of  receiving  and  acting  upon  ESPDUs,  fire  PDUs,  and  detonation  PDUs. 

•  Capable  of  running  for  at  least  eight  hours  with  human  intervention  as  required. 

•  Capable  of  running  at  or  representing  real-time  actions. 

•  Must  use  terrain  data  base  at  least  200  kilometers  (km)  by  200  km  and  based  on  National  Imagery 
and  Mapping  Agency  products. 

•  Must  have  a  V&V  history,  an  accreditation  history  for  analysis,  be  under  configuration  control,  and 
be  well  documented. 

•  Must  reasonably  represent  entity  movement,  stopping,  and  turning. 

•  Must  represent  the  effects  of  a  bombing  or  missile  attack  on  the  entities  represented  in  an 
acceptable  and  credible  maimer. 

This  analysis  indicated  that  none  of  the  constructive  simulations  would  meet  the  ETE  requirements 
without  modification  and  development.  JADS  ETE  identified  the  following  criteria  fiom  the 
requirements  for  selecting  which  simulation  to  modify. 

1.  Capable  of  producting  large  numbers  (1000s)  of  “inteUigenf’  (semiautomated,  nonscripted, 
nontemplated,  human  controllable)  interactive  entities. 

2.  Capable  of  conducting  the  simulation  in  a  large  terrain  box  (preferably  at  least  200  km  by  200  km) 
while  operating  at  the  entity  level  described  in  1. 
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3.  Previously  verified  and  validated  (preferably  by  the  Army)  for  combat  development  and  OT/DT 
studies. 

4.  DIS  compatible. 

Table  2  provides  the  comparison  of  the  constmctive  simulations  which  led  to  the  selection  of  the  Janus 
simulation  as  the  best  candidate  for  upgrading  to  meet  our  requirements. 

Table  2.  Constructive  Simulation  Comparison 


CRITERIA 

EAGLE 

CBS 

BBS 

JCM 

STAGE 

JANUS 

MODSAF 

1 

No 

No 

No 

No 

No 

Yes 

No 

2 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

No 

3 

No 

No 

No 

No 

No 

Yes 

No 

4 

Yes 

No 

Yes 

No 

No 

Yes 

Yes 

Janus  is  under  the  configuration  control  of  the  U.S.  Army  Training  and  Doctrine  Command  (TRADOC) 
Analysis  Command,  White  Sands  Missile  Range  (TRAC-WSMR)  and  the  Army  Simulation,  Training, 
and  Instrumentation  Command  (STRICOM).  JADS  entered  into  an  agreement  with  TRAC-WSMR  to 
modify  Janus,  as  appropriate,  to  be  able  to  represent  at  least  5000  entities.  The  entity-level  data 
generated  by  Janus  will  be  converted  into  ESPDUs  by  an  interface  developed  by  TRAC-WSMR  for 
that  purpose. 

Janus  is  an  interactive,  computer-based  simulation  of  combat  operations  conducted  by  platoons  through 
brigades.  The  original  Janus  simulation  began  in  the  late  1970s  at  Lawrence  Livermore  National 
Laboratories  to  provide  commanders  interactive  control  of  a  combat  simulation  in  the  presence  of 
nuclear  effects.  In  1983,  TRAC-WSMR  obtained  Janus  and  enhanced  Janus  as  a  high-resolution 
simulation  to  support  analysis  for  Army  combat  development.  In  1991,  TRADOC  selected  Janus  for 
training  at  the  company  and  platoon  levels.  Janus  has  also  been  used  by  the  Command  and  General 
Staff  College  to  train  new  battalion  and  brigade  commanders  on  the  principles  of  synchronized 
combined  arms  operations. 

Janus  is  a  suite  of  programs  with  over  200,000  lines  of  FORTRAN  code.  These  programs  produce  an 
environment  that  allows  the  user  to  set  up  the  desired  battle.  Terrain,  performance  data,  forces,  unit 
symbols,  and  command  and  control  overlays  are  typical  entities  that  can  be  edited  to  suit  the  user. 
Interactive  graphics  programs  such  as  the  Janus  analyst  workstation  (JAAWS)  and  the  controller 
workstation  add  to  the  utihty  of  the  Janus  user’s  application  tools. 

TRAC-WSMR  has  an  ongoing  program  of  enhancement  and  improvement  of  Janus.  JADS  entered 
into  an  agreement  with  TRAC-WSMR  and,  with  other  programs,  has  sponsored  various  enhancements 
to  Janus  to  allow  it  to  meet  ETE  requirements.  The  result  of  these  efforts  is  Janus  6.88D.  Janus  6.88D 
provides  capabilities  which  include  enhancements  sponsored  by  JADS  or  other  programs  in  the 
following  areas. 
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The  number  of  units  allowed  in  Janus  was  extended  from  1200  to  6000,  then  to  8000,  and  most 
recently  to  9999  in  Janus  6.88D.  Initial  tests  of  even  the  first  extension  to  6000  units  revealed  that 
versions  would  not  run  real  time.  Further  testing  revealed  the  cause  to  be  the  updating  of  the  unit 
locations  on  the  graphic  display.  Major  changes  were  required,  and  the  solutions  were  creative,  based 
on  solid  computer  science  theory,  and  extremely  useful.  In  order  to  reduce  the  graphic  update  time 
required,  a  process  called  heterogeneous  aggregation  (HA)  was  implemented.  The  interactor  is  able  to 
dynamically  select  the  level  of  detail  of  the  units  displayed  on  the  graphic  screen.  A  graphics  interface 
was  added  to  the  Force  editor  that  allows  the  user  to  build  and  modify  a  force  according  to  mihtaiy 
oiganizations  witii  specification  to  the  entity  level  possible  at  any  level  of  aggregation.  No 
phenomenology  was  changed  for  HA;  the  war  fighting  engine  stiU  operates  at  the  entity  level.  Janus 
was  modified  to  allow  deployment  and  route  building  for  organizations.  The  large  numbers  of  units  did 
require  that  some  functions  not  directly  related  to  HA  be  modified.  Even  more  changes  were  made 
after  observing  users  struggle  with  building  large  scenarios.  Several  modifications  were  made  to  reduce 
the  labor  of  the  user.  The  implementation  of  HA  is  of  broad  general  use  to  aU  Janus  users  and  has  been 
a  tremendous  benefit  to  the  U.S.  Army.  Of  the  many  benefits  of  the  JADS  project,  the  addition  of  this 
capability  to  Janus  is  certainly  a  significant  one. 

Prior  to  the  JADS  project,  TRAC-WSMR  used  an  external  program  called  Janus  Distributed 
Interactive  Simulation  (JanDIS)  which  ran  on  the  same  host  and  shared  memory  with  Janus,  the  combat 
model  program,  to  communicate  with  other  systems  on  a  network.  Practical  use  in  JADS  and  other 
distributed  projects  revealed  that  the  arrangement  was  too  hard  to  use.  The  DIS  interface  was 
integrated  into  Janus  with  a  graphical  interface  for  user  control  of  runtime  parameters.  The  firing  and 
detonation  PDUs  were  implemented  and  tested  in  the  JADS  network  in  coordination  witii  the  Tactical 
Army  Fire  Support  Model  (TAFSM). 

When  Janus  is  used  in  a  stand-alone  exercise,  the  Janus  analyst  workstation  (JAAWS)  program  is  used 
as  an  after  action  review  (AAR)  tool.  When  Janus  is  part  of  a  distributed  application,  information  from 
entities  not  under  control  of  Janus  would  not  be  available  to  JAAWS.  Janus  Plan  View  Display 
(JanPVD)  was  developed  from  the  JAAWS  pattern  to  display  PDUs  from  all  sources.  JanPVD  can 
run  in  the  live  mode  displaying  information  in  real  time,  or  it  can  run  from  recorded  data  to  provide 
replay  capability.  JariPVD  displays  position,  losses,  direct  fires,  indirect  fires,  and  artillery  impacts. 
The  user  can  select  from  six  different  graphs  of  analysis  measures  over  time.  In  the  replay  mode,  the 
user  has  the  additional  capability  to  display  movement  and  routes. 

3.1.2  Joint  STARS  Simulation  -  VSTARS 

The  primary  interface  between  tiie  synthetic  environment  and  the  Joint  STARS  system  is  a  simulation  of 
the  Joint  STARS  radar.  The  phasing  of  the  program  required  two  versions  of  the  simulation,  a 
laboratory  version  for  Phases  1-2  and  a  version  that  could  be  installed  on  the  aircraft  for  Phases  3-4. 
The  requirements  for  the  simulation  are  as  follows. 
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•  Joint  STARS  simulation  shall  enable  the  mixing  of  MTI  radar  virtual  entities,  terrain,  and  SAR 
images  in  a  seamless  manner  with  the  actual  radar  images  produced  by  the  E-8C  while  performing 
an  operational  mission. 

•  Joint  STARS  simulation  will  operate  within  the  timeUne  standards,  utili2e  the  same  system 
parameters,  and  use  the  same  message  formats  established  for  the  Joint  STARS  radar  system. 

•  When  installed  on  the  E-8C,  Joint  STARS  simulation  will  provide  simulated  radar  data  integrated 
with  live  radar  data  when  operating  within  the  ETE  synthetic  environment. 

•  For  MTI  radar  reports.  Joint  STARS  simulation  will  allow  operation  in  three  modes:  Uve,  where  all 
data  are  provided  by  the  radar  operating  system;  mixed,  where  both  live  and  virtual  data  are 
provided;  and  virtual,  where  all  data  are  provided  by  tire  synthetic  environment  and  the  Joint 
STARS  simulation.  SAR  reports  will  be  either  real  or  virtual  with  no  mixing. 

In  aU  modes  of  operation.  Joint  STARS  simulation  will  permit  all  of  the  normal  operations  performed  by 
the  console  operator  to  remain  possible,  such  as  target  tracking,  target  type  identification,  etc.,  even 
though  most  or  all  of  the  targets  are  virtual  entities. 

When  working  on  a  Joint  STARS  simulation  supplemented  workstation,  the  operator  should  not  be  able 
to  easily  distinguish  between  live  and  virtual  targets,  either  visually  or  as  a  result  of  any  action  normally 
taken  in  the  course  of  performing  duties. 

The  ETE  team  surveyed  existing  simulations  of  the  Joint  STARS  radar  modes  with  the  following  results. 

Radar  Modes 

•  None  of  the  existing  simulations  of  the  moving  target  indicator  (MTI)  mode  of  the  Joint  STARS 
radar  duplicated  the  actual  radar  characteristics. 

•  There  were  no  simulations  of  the  synthetic  aperture  radar  (SAR)  mode  of  the  Joint  STARS  radar. 
The  best  existing  simulation  provided  a  limited  number  of  canned  images  bearing  no  operational 
relevance  to  the  scenario. 

•  The  lack  of  a  SAR  simulation  precluded  support  of  the  fixed  target  indicator  (FTI)  mode  of  the  Joint 
STARS  radar. 

System  Representation 

•  The  existing  simulations  were  either  E-8C  workstation  simulations  or  ground  station  module 
stimulators. 
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•  The  existing  simulations  provided  no  intersystem  interaction  and  therefore  were  not  designed  to 
operate  with  actual  E-8C  components. 

•  The  existing  simulations  did  not  provide  all  the  operator  functionahty. 
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Intersystem  Timelines 


•  The  existing  simulations  used  fixed  estimates  of  the  intersystem  timelines  and  therefore  were  not 
driven  by  loading  on  the  system. 

Due  to  the  lack  of  any  existing  simulation  to  meet  the  requirements,  JADS  initially  contracted  with 
Northrop  Grumman  to  evaluate  system  architectures  and  develop  an  engineering  design  of  the  selected 
architecture.  The  architectural  study  recognized  the  primary  challenge  for  the  Joint  STARS  simrrlation 
was  its  integration  on  the  aircraft.  Therefore,  the  study  evaluated  three  candidate  architectures  for  the 
aircraft  version  of  the  simulatiorL 

•  Minimize  the  message  traffic  on  the  hardware  busses  and  contain  the  simulation  on  the  same 
processing  unit  as  the  existing  MTI  processing. 

•  Minimize  the  impact  on  existing  processing  by  isolating  the  simulation  in  an  independent  processor. 

•  Increase  the  fidelity  of  the  simulation  or  lower  the  level  at  which  the  simulation  wiU  be  performed. 

Each  of  the  three  architectures  was  designed  to  the  level  required  to  evaluate  them  against  the  following 
criterion: 

Timeline  Impact 
Memory  Requirements 
System  Loading 

Modification  of  Existing  Software 
Modification  or  Addition  of  Hardware 
Use  of  Existing  Simulations  and  Models 
Level  of  Simulation 
Integration  Complexity 
Expandibftity/Growth 

The  first  candidate  was  found  to  have  minimal  direct  impact  to  the  timeline,  however,  the  radar  data 
processor  would  have  increased  load  and  would  impact  the  existing  MTI  processing.  The  integration 
complexity  of  this  architecture  was  considered  large,  and  the  architecture  did  not  support  expansion 
without  impacting  existing  processing. 

The  second  candidate  was  found  to  have  no  impact  on  the  timeline,  memory  or  system  loading.  This 
candidate  required  a  reconfiguration  of  the  system  configuration  to  use  the  spare  general  purpose 
computer  (GPC).  Integration  complexity  was  reduced,  and  the  architecture  could  be  expanded  to  the 
maximum  capabihty  of  the  GPC. 

The  third  candidate  was  expected  to  impact  the  timeline  as  a  function  of  target  load.  This  candidate 
required  the  largest  development  While  the  first  two  candidates  limited  the  level  of  the  simulation  to  the 
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MTI  report,  fliis  architecture  would  include  all  sections  of  the  MTI  processing  up  to  the  signal 
processor.  Integration  was  considered  equivalent  to  candidate  2.  While  the  expandibility  of  this 
candidate  was  only  limited  by  the  capacity  of  the  GPC,  the  limitation  on  the  number  of  targets  limited  the 
growth  of  this  architecture. 

The  resulting  recommendation  was  to  adopt  the  second  architecture  for  JADS  requirements.  Candidate 
3  was  identified  as  a  future  possibihty  for  implementation  because  of  the  expanded  testing  capabilities. 
Appendix  A,  Architectural  Design  Report  for  the  Radar  Processor  Simulation  for  the  Joint  Surveillance 
Target  Attack  Radar  System  (Joint  STARS),  is  the  resulting  report  for  this  study. 

Following  the  selection  of  the  appropriate  architecture,  Northrop  Grumman  conducted  an  engineering 
design  of  the  radar  processor  simulation  and  prepared  a  specification  of  the  system-level  requirements 
for  the  radar  processor  simulation.  Appendix  B,  Engineering  Design  Report  for  the  Radar  Processor 
Simulation  for  the  Joint  Surveillance  Target  Attack  Radar  System  (Joint  STARS),  documents  the 
hardware  and  software  requirements  for  the  radar  processor  simulation. 

During  the  joint  feasibility  study  (JFS)  phase  of  the  JADS  JT&E,  the  ETE  team  identified  the  lack  of  a 
SAR  simulation  for  the  Joint  STARS  radar  to  be  one  of  the  key  risk  areas  for  the  ETE  test.  In  parallel 
with  the  JFS,  the  Advanced  Research  Projects  Agency  conducted  a  trade  study  of  13  existing  SAR 
simulation  eapabilities  in  support  of  the  War  Breaker  program.  The  War  Breaker  requirements  were 
similar  to  the  JADS  requirements,  and  the  ETE  program  entered  into  an  agreement  with  the  War 
Breaker  to  cooperate  on  the  development  of  the  SAR  simulation.  As  a  result  of  the  trade  study,  the 
War  Breaker  identified  two  candidates  as  having  the  potential  to  be  used  as  a  baseline  for  the 
development  of  a  SAR  simulation.  These  vendors  were  requested  to  submit  a  rough  order  of  magnitude 
estimate  for  the  development,  and  Loral  Defense  Systems,  Goodyear,  Arizona,  was  requested  to  submit 
a  proposal  for  a  Radar  Image  Simulation  System  (RISS)  to  be  based  on  the  XPATCHES  simulation 
developed  under  sponsorship  of  Wright  Laboratory.  The  RISS  was  conceived  as  a  generic  SAR 
simrdation  which  would  be  capable  of  simulating  SAR  capabilities  of  Joint  STARS,  Tier  II+/ni 
Unmanned  Aeriel  Vehicles,  and  the  U-2R  platforms.  During  contractual  negotiations,  the  War  Breaker 
program  was  canceled  and  JADS  ETE  was  left  without  a  partner  for  the  SAR  simulation  development. 
In  cooperation  with  Wright  Laboratory,  JADS  contracted  with  Lockheed  Martin  Tactical  Defense 
Systems,  the  successor  of  Loral,  to  develop  a  Joint  STARS  specific  SAR  simulation.  This  system  is 
called  the  Advanced  Radar  Imaging  Emulation  System  (ARIES). 

In  1996,  JADS  ETE,  in  cooperation  with  Rome  Laboratory,  contracted  with  Northrop  Grumman  to 
develop  a  Joint  STARS  E-8C  simulation,  consisting  of  a  radar  processor  simulator  and  integrator 
(RPSI),  a  distributed  interactive  simulation  network  interface  unit  (DIS  NIU)  and  a  data  link  databus 
interfece  unit.  This  simulation  would  be  developed  in  accordance  widi  architecture  candidate  2  and 
would  be  capable  of  integrating  a  SAR  simulation  developed  under  another  contract. 

The  resulting  Joint  STARS  E-8C  simulation  is  called  the  Virtual  Surveillance  Target  Attack  Radar 
System  (VSTARS),  an  emulation  that  represents  the  radar  subsystem  of  the  Joint  STARS  E-8C  in  a 
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laboratory  environment.  It  is  composed  of  the  DIS  NIU,  the  RPSI  that  contains  the  two  real-time  radar 
simulations  with  necessary  databases,  and  various  simulations  of  E-8C  processes. 
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- > 

ESPDUs 


CDP  -  central  data  processor  SM&C  -  system  management  and  control 

M&IS  -  management  and  integration  software  SMO  -  system  management  officer 


Figures.  VST ARS Architecture 

The  DIS  NIU  functions  are  divided  between  two  components.  The  ground  NIU  is  connected  to  the 
DIS  network  and  receives  entity  state  protocol  data  units  (ESPDUs)  from  the  network.  It  also 
performs  coordinate  conversion  to  the  radar’s  coordinate  system  and  reduces  the  ESPDUs  from  the 
standard  1 152  bits  to  192  bits.  (See  Appendix  C.)  This  reduced  data  packet  is  then  sent  to  the  air 
NIU  where  dead  reckoning  is  performed.  The  splitting  of  the  NIU  is  required  because  the  RPSI  wiU  be 
integrated  into  an  actual  E-8C  allowing  the  mix  of  live  and  virtual  targets  onboard  the  aircraft.  The 
ESPDU  is  reduced  in  size,  and  dead  reckoning  is  performed  by  the  air  NIU  in  order  to  reduce 
bandwidth  requirements  for  the  link  between  the  two  NIUs. 

The  RPSI  completes  the  concept  for  mixing  real  and  virtual  radar  returns.  It  mixes  virtual  MTI  returns 
on  virtual  terrain,  and  virtual  S AR  images  with  actual  radar  returns  without  causing  any  degradation  of 
the  aircraft  system’s  capability  for  handling  actual  (live)  targets.  The  RPSI  is  based  on  the  architecture 
of  the  aircraft  radar  subsystem  and  functions  within  the  actual  radar  processor  software.  It  is  triggered 
by  the  same  message  structures  currently  used  to  communicate  witii  and  within  the  radar  subsystem; 
nominally  works  within  the  radar  subsystem  timelines;  and  ou^ruts  its  reports  in  the  same  formats 
currently  used  by  the  radar  subsystem. 
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When  integrated  into  the  radar  subsystem  of  the  E-8C,  the  RPSI  architecture  is  designed  to  function  in 
three  primary  modes. 

1 .  All  real,  where  only  the  aircraft’s  radar  subsystem  is  providing  information  on  the  real  environment. 

2.  Mixed  mode,  where  both  the  radar  subsystem  and  the  RPSI  are  providing  information  on  the  real 
and  virtual  environment. 

3 .  Virtual  mode,  where  only  the  RPSI  is  providing  information  on  the  virtual  environment. 

The  MTI  simulation  developed  by  Northrop  Grumman  and  used  in  VSTARS  is  based  upon  an 
engineering  model  used  during  the  development  of  the  E-8C  radar.  As  such,  it  went  through  many 
cycles  of  model-test-model  and  is  considered  to  be  a  vahd  model  of  the  MTI  mode  of  the  E-8C  radar. 
It  characterizes  target  probability  of  detection  (Pd)  and  location  accuracy,  in  the  presence  of  clutter 
assuming  a  constant  false  alarm  rate,  as  a  function  of  key  radar  system  variables  that  can  be 
implemented  in  the  real-time  target  detection  stream  of  the  MTI  radar  system. 

The  simulation  receives  programmable  signal  processor  (PSP)  messages  that  indicate  the  limits  of  the 
current  radar  beam  footprint  (dwell  quadrilateral)  and  determines  what  portion  of  the  footprint  is 
allowed  virtual  targets.  It  then  determines  which  moving  virtual  targets  are  located  within  the  virtual 
portion  of  the  dwell  quadrilateral,  based  upon  their  latest  dead  reckoned  position.  Once  the  possible 
target  set  is  determined,  Pd  is  applied  and  the  detected  target  set  is  derived.  Location  error  is  then 
applied  to  the  detected  targets  and  the  target  set  is  sent  to  the  radar  post  processor.  A  false  alarm 
simulation  runs  whenever  the  MTI  simulation  is  operating  in  the  ‘virtual  only’  mode.  This  generates  false 
returns,  including  meteorological  effects,  based  upon  radar  system  variables.  A  flow  diagram  for  the 
MTI  simulation  is  shown  in  Figure  4. 


15 


^  Radar  Service  Request 


SCHEDULE  AND 
CONTROL 


^;r;v.  /'.yy  :/^'- 


MOTION 
COMPENSATION 


<“ "  ’ir<<-^  J'ii:i^’>'^>i,~(  <{■  ’4K 


Mode 


Command 
Auxiliary 


i  I 

Live  MTI  Report 


I&Q  -  in-phase  and  quadrature  (radar  data)  VDPS  -  VSTARS  data  packet 

Figure  4.  VSTARS  MTI  Flow  Diagram 

The  SAR  simulation,  ARIES  extends  flie  capabilities  of  XPATCH  target  signature  modeling, 
XPATCHES  image  scene  generation,  and  interfaces  with  Northrop  Grumman’s  RPSI  to  provide  a 
complete  methodology  for  the  real-time  simulation  of  the  Joint  STARS  SAR  mode  of  operation. 

ARIES  will  be  initiated  by  the  receipt  of  a  radar  service  request  requesting  a  SAR  image  with  an  image 
center  point  specified  within  the  virtual  portion  of  the  ground  radar  coverage  area  (GRCA).  The  GRCA 
covers  thousands  of  square  kilometers,  is  specified  in  the  mission  orders,  and  is  the  area  scanned 
continuously  by  MTI  wide  area  surveillance.  It  also  acts  as  a  limiting  area  for  special  radar  products 
such  as  a  SAR  image.  The  virtual  portion  of  the  GRCA  will  be  so  indicated  upon  initialization  of  the 
RPSI.  ARES,  upon  initialization  of  the  RPSI,  will  create  three  data  bases  within  hardware  random 
access  memory  (RAM)  containing  elevation  and  feature  data  for  the  GRCA,  and  a  feature  target 
function  library  for  all  the  features  contained  in  the  feature  data  base. 

Once  the  center  point  of  the  virtual  SAR  image  is  known,  ARES  will  over  sample  around  the  center 
point  and  extract  the  elevation  data  for  an  area  that  will  exceed  the  image  area  coverage.  ARES 
determines  from  the  contour  algorithms  if  any  terrain  feature  outside  the  image  area  wifi  influence  the 
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image  area.  ARES  will  also  determine  which  terrain  features  exist  within  the  target  area.  Using  this 
data,  ARES  will  develop  a  ground  tmth  point  map  of  the  sampled  area. 

ARES  will  wait  for  the  PSP  parameter  message  to  arrive  before  doing  any  further  processing.  The 
PSP  parameter  message,  a  product  of  the  actual  scanning  of  the  area  of  interest  (AOI)  by  the  radar, 
contains  such  information  as  actual  gra2dng  and  squint  angles,  size  of  imaged  area,  and  other  information 
needed  by  ARES  to  image  the  AOI.  Once  the  PSP  parameter  message  is  received,  ARES  will  select 
the  actual  image  area  from  the  ground  truth  point  map  and  begin  applying  XPATCHES  image 
generation  algorithms  to  generate  the  SAR  scene.  The  SAR  flow  diagram  is  shown  in  Figure  5. 


Radar  Service  Request 


^  Live  SAR  Report 


Figure  5.  VSTARS  SAR  Flow  Diagram 

The  RPSI  will  also  receive  the  PSP  parameter  message  and  will  use  the  actual  imaged  area  to  determine 
what  virtual  targets  are  located  within  the  AOI.  It  will  then  send  this  target  list  to  ARES,  which  wiU 
obtain  from  feature  target  function  libraries  the  appropriate  target  image  chips  for  insertion  into  the  SAR 
image.  Moving  targets  will  be  displaced,  or  smeared,  within  the  image  as  appropriate.  Once  this  is 
accomplished,  the  image  will  be  sent  to  the  RPSI  for  forwarding  to  the  post  processor.  Timing  studies 
indicate  that  it  will  take  ARES  up  to  three  times  longer,  depending  on  the  processor,  to  generate  a 
SAR  image  than  the  real  radar.  Since  the  requester  has  no  way  of  knowing  when  the  SAR  mission  was 
initiated,  we  do  not  feel  fliat  this  delay  will  be  noticed. 
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Both  the  MTI  and  SAR  simulations  allow  the  radar  operators  to  perform  all  of  their  required  functions. 

The  primary  difference  between  VSTARS  operating  within  the  laboratory  and  the  RPSI  operating  on 
board  the  real  E-8C  is  the  need  to  simulate  the  navigation  subsystem  and  certain  radar  components 
within  the  laboratory.  These  simulations  make  it  possible  for  VSTARS  to  function  without  an  E-8C 
present. 

In  use,  VSTARS  must  be  connected  to  an  operator’s  workstation,  currently  the  Advanced  Technology 
Work  Station,  that  serves  as  the  interface  between  the  aircraft  crew  and  the  radar.  VSTARS  output 
can  also  be  sent  to  the  ground  component  of  Joint  STARS  via  a  virtual  surveillance  control  data  link 
(SCDL). 

Appendices  4  and  5  document  the  Phase  1  efforts  of  Northrop  Grumman  and  Lockheed  Martin 
respectively. 

3.1.3  Surveillance  Control  Data  Link  Interface 

Joint  STARS  consists  of  two  segments:  the  air  segment  consisting  of  the  E-8C  and  the  ground  segment 
consisting  of  a  ground  station  module  (GSM)  or  a  common  groimd  station  (CGS).  These  segments  are 
connected  via  a  line-of-sight  radio  frequency  data  link  called  the  surveillance  control  data  link.  This  data 
link  supports  the  transfer  of  radar  products  from  the  E-8C  to  die  GSM/CGS  and  allows  the  GSM/CGS 
operators  to  submit  radar  service  requests  to  the  E-8C.  Additionally,  the  data  link  supports  free  text 
messaging  between  the  E-8C  and  the  GSM/CGS. 

The  initial  concept  for  connecting  the  VSTARS  and  the  GSM/CGS  was  to  encapsulate  the  SCDL 
messages  in  a  DIS  message  PDU.  Upon  more  detailed  research  the  ETE  team  discovered  the 
necessary  data  concerning  the  SCDL  were  not  releasable,  and  that  the  team  would  be  unable  to 
encapsulate  the  data.  The  next  approach  was  to  transmit  the  SCDL  directly  over  a  wide  area  network 
link.  In  this  case,  the  team  discovered  they  were  unable  to  make  the  intmsive  link  into  die  ground  data 
terminal  (GDT)  of  the  GSM/CGS.  The  final  solution  for  making  this  connection  was  to  capture  the  data 
prior  to  their  transformation  into  SCDL  data  and  transmit  these  data  between  VSTARS  and  the 
GSM/CGS.  In  VSTARS  this  entailed  capturing  the  data  prior  to  the  SCDL  process,  and  in  the 
GSM/CGS  the  data  are  bridged  from  a  local  area  network  connection  to  the  military  standard  (MDDL- 
STD)  1553  databus  in  the  GSM/CGS. 

The  VSTARS  data  link  databus  interface  unit  consists  of  a  software  process  within  VSTARS  that 
establishes  a  connection  between  VSTARS  and  the  GDT  1553  bus  interface  unit  (BIU)  at  the 
GSM/CGS.  This  cormection  uses  the  transmission  control  protocol  to  establish  a  reliable 
communications  link  via  a  local  area  network  connected  to  the  VSTARS  processor,  a  secure  wide  area 
network  link,  and  the  local  area  network  cormected  to  the  GDT  1553  BIU. 
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The  interface  between  the  VSTARS  data  link  databus  interface  unit  and  the  GDT  1553  BIU  is 
controlled  by  an  interface  control  document  between  Northrop  Grumman  and  Motorola 
Communications  System  Division.  (Appendix  F) 

The  GDT  1553  BIU  was  developed  by  Motorola  Communications  Systems  Division,  Scottsdale, 
Arizona.  Motorola  is  also  the  developer  and  producer  of  both  the  GSM  and  the  CGS.  The  GDT  1553 
BIU  consists  of  a  Sun  SPARC  5  workstation  with  both  Ethernet  and  MIL-STD  1553  interface  cards. 
The  BIU  is  integrated  with  the  GSM/CGS  is  such  a  way  that  the  GSM/CGS  operator  must  establish  a 
SCDL  using  the  normal  operational  procedures  and  commands  before  the  BIU  will  allow  the 
connection  via  the  wide  area  network. 

Appendix  G  is  the  software  test  plan  for  the  GDT  1553  BIU.  JADS  ETE  established  a  communications 
link  with  Northrop  Grumman  in  Melbome,  Florida,  to  support  integration  among  the  contractors  and 
testing.  The  initial  test  was  conducted  at  the  Motorola  facility  in  July  1997  between  prototype  CGSs 
and  VSTARS.  In  this  test,  a  data  dropout  problem  was  identified  which  could  not  be  isolated.  The 
decision  was  made  to  accept  the  BIU  pending  its  integration  with  an  operational  GSM  at  Fort  Hood, 
Texas.  In  February  1998,  the  GDT  1553  BIU  was  integrated  with  two  hght  ground  station  modules  at 
Fort  Hood.  The  test  was  successfully  repeated  during  this  integration  period.  We  believe  the 
combination  of  controlling  the  speed  of  the  data  link,  a  normal  function  with  the  actual  SCDL,  coupled 
with  a  stable  test  environment  of  operational  GSMs,  rather  than  prototype  CGSs,  solved  this  integration 
problem. 

3.2  End-to-End  Network 

The  ETE  network  was  designed  to  be  a  dedicated  network  based  on  commercial  communications  links 
using  DIS  protocols  where  appropriate.  The  ETE  team  developed  an  engineering  process  for 
identifying  the  requirements  for  any  network  configuration  considered.  As  the  makeup  of  the  ETE 
synthetic  environment  evolved  during  the  planning  stages  of  Phase  1,  the  ETE  team  used  this  process  to 
refine  the  requirements  for  the  ETE  network.  We  will  describe  this  process  in  terms  of  the  network 
integrated  at  the  end  of  Phase  1. 

3.2.1  Network  Requirements  Analysis 

The  first  step  in  the  process  is  to  conduct  a  flow  analysis  of  the  data  required.  Each  node  is  examined 
to  identify  the  data  required  from  other  nodes  and  the  data  supplied  to  other  nodes.  Figure  6  is  ETE 
data  flow  diagram. 

In  addition  to  the  PDU  and  data  link  data  identified  in  the  diagram,  each  site  is  connected  with  a 
dedicated  voice  link  for  test  control. 
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Figure  6.  EXE  Data  Flow  Diagram 

The  second  step  in  the  process  is  to  estimate  the  amount  of  data  required  to  pass  between  the  nodes. 
For  example,  the  estimate  for  the  entity  state  PDUs  from  WSMR  to  the  TCAC  is  made  using  the 
Mowing  calculation: 

Assumptions:  9500  entities  publishing  ESPDUs  with  a  heartbeat  of  1  minute 
No  more  than  25%  of  the  entities  moving  during  any  second 
No  more  than  1%  of  the  moving  entities  changing  state  during  any  second 
ESPDU  consists  of  1 152  bits 
PDU  protocol  overhead  is  288  bits 

Heartbeat  Requirement:  9500  entities  /  60  seconds  =  158.3  PDUs  per  second 
State  Change  Requirement;  9500  entities  X  .25  =  2375  movers 

2375  movers  X  .01  =  23.75  PDUs  per  second 

Total  ESPDUs  per  second:  183  per  second 
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Total  bandwidth  required:  183  PDUs  per  second  X  1440  bits  =  263,520  bits  per  second 
Each  flow  between  two  nodes  is  estimated  using  similar  calculations  and  the  total  flow  between  the  two 
nodes  is  calculated.  Additionally,  network  management  overhead  is  estimated  and  added  to  the  total. 
The  resulting  estimated  requirement  for  the  WSMR  -  TCAC  example  is  calculated  below: 


ESPDUsfromWSMR 
ESPDUstoWSMR 
Fire  PDUs  to  WSMR 
Detonate  PDUs  to  WSMR 
Voice  Channel 
Network  Management 
Total  Requirement 
Safety  Factor  (X  2) 


263,520  bps  (bits  per  second) 
2,880  bps 
768  bps 
832  bps 
64,000  bps 
500  bps 
332,500  bps 
665,000  bps 


The  final  step  in  the  process  is  to  determine  the  appropriate  size  of  the  commercial  link  between  the 
nodes.  In  general,  commercial  links  are  sold  as  channels  each  having  a  64,000  bps  capacity  and  T 
carriers  consisting  of  multiple  channels,  e.g.,  a  T-1  link  having  24  channels  (1.544  megabits  per  second). 
The  example  above  would  require  1 1  channels  or  a  single  T-1  link. 

The  ETE  team  performed  numerous  estimates  of  the  network  requirements  based  on  varying 
assumptions  and  configurations.  Based  on  these  various  estimates,  the  requirements  for  the  ETE 
network  showed  above  were  as  follows: 


WSMR -TCAC  T-1 

TCAC  -  Northrop  Grumman  T-1 

TCAC  -  Fort  Hood  2  channels 

TCAC  -  Fort  Sill  4  channels 

Northrop  Grumman  -  Fort  Hood  4  channels 


1.544  Mbps  (megabits  per  second) 
1.544  Mbps 
.128  Mbps 
.256  Mbps 
.256  Mbps 


Although  the  estimated  requirements  for  three  of  the  links  were  less  than  T-1  capacity,  we  determined 
during  procurement  that  commercial  vendors  charged  less  for  T-1  links  than  for  fiactional  T-1  links. 
Therefore,  all  the  links  for  the  ETE  network  are  T-1 . 


3.2.2  End-to-£nd  Network  Security 

Security  presented  a  problem  for  the  ETE  networic.  The  initial  concept  for  the  ETE  network  was  for  an 
encrypted  network  protected  at  the  secret  level.  As  the  team  coordinated  the  requirements  with  the 
various  nodes,  we  determined  that  supporting  a  classified  network  presented  problems  for  three  of  the 
nodes.  The  Northrop  Grumman  node  was  the  node  which  required  protection  and  any  connection  to 
this  node  would  also  require  protection.  Through  analysis  of  the  data  flows  identified  above,  we 
determined  that  the  only  data  flowing  fi-om  Northrop  Grumman  was  a  single  ESPDU  per  second  which 
would  only  be  used  for  test  control.  Therefore,  we  determined  that  if  we  could  establish  a  security 
guard  or  an  air  gap  between  the  sites  desiring  to  operate  at  the  unclassified  level  and  the  TCAC, 
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Northrop  Grumman,  and  the  GSM,  we  could  overcome  the  problems  at  these  sites.  Figure  7  describes 
the  resulting  network. 


VSTARS  and 
Logger 
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Janus  6.88D 

T-l  Link 
<  (DISA'oice) 

T-l  Link  ^ 
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FtSiHOK 


Classified 
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CAMPS  -  Compartmented  All  Source  Analysis  System  Message  Processing  System 


TAC  -  target  analysis  cell 


Figure  7.  EXE  Network 


The  initial  separation  between  the  unclassified  segment  and  the  classified  segment  was  effected  by 
developing  an  unclassified  annex  of  the  TCAC  and  connecting  it  with  a  low  to  high  security  guard 
consisting  of  a  simplex  encrypted  link.  This  link  allows  traffic  fixam  the  unclassified  segment  to  be 
passed  to  the  classified  segment,  but  blocks  traffic  from  the  classified  segment  from  flowing  to  the 
unclassified  segment.  The  other  break  occurs  at  Fort  Hood.  The  Compartmented  ASAS  Message 
Processing  System  (CAMPS)  is  a  configuration  of  the  All  Source  Analysis  System  (ASAS)  which  is 
certified  as  a  high  to  low  security  guard.  This  system  is  being  used  in  the  ETE  network  to  separate  the 
secret-level  GSM  fi'om  the  unclassified  segment  of  the  network. 


3.2.3  End-to-End  Network  Characterization 


The  JADS  JTF  identified  network  technology  as  a  potential  concern  or  constraint  for  using  ADS  for  test 
and  evaluation.  The  JADS  evaluation  methodology  identifies  several  measures  used  to  evaluate  the 
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network  related  concerns  and  constraints.  The  following  measures  were  evaluated  in  part  or  in  whole  in 
Phase  1. 
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M  2- 1-2-3  Average  and  peak  bandwidth  used  by  link. 

M  2- 1-2-6  Percentage  of  total  PDUs  required  at  a  node  that  were  delivered  to  that  node. 

M  2- 1-2-7  Average  and  peak  data  latencies  between  ADS  nodes. 

The  JADS  Network  and  Engineering  and  Analysis  teams  in  conjunction  with  the  ETE  team  developed  a 
process  for  characterization  of  a  networic  link  prior  to  its  integration  into  a  synthetic  environment.  At 
Appendix  H  are  the  results  of  characterization  tests  conducted  by  Northrop  Grumman,  WSMR,  Fort 
Hood,  and  Fort  SiQ  links,  respectively.  An  instrumentation  limitation  exists  in  JADS  ability  to  measure 
average  and  peak  bandwidth  for  all  the  ETE  links.  The  particular  instrumentation  suite  used  to  measure 
bandwidth  utilization  is  called  SPECTRUM.  This  instrumentation  suite  is  installed  in  the  classified 
portion  of  the  TCAC  and  is  currently  classified  secret.  Therefore,  we  cannot  use  it  to  measure 
bandwidth  utilization  for  unclassified  links.  This  limitation  is  reflected  in  the  data  reported  below  and  in 
the  appendices.  The  tables  below  summarize  the  results  of  these  tests. 


Table  3.  Bandwidth  Utilization  for  Grumman  Link 


Times 

Expected  Rate 
(XE.R.) 

Rate  (PDU/sec) 

Number  PDUs 
Received 

Bandwidth 
Utilization  (%) 

1  X  E.R. 

100 

11859 

10 

2  X  E.R. 

11858 

21 

3XE.R. 

11853 

28 

4XE.R. 

400 

11847 

40 

5XE.R. 

500 

10492 

45 

Table  4.  PDU  Verification  Test  Results 


No.  of  PDUs 

No.  of  PDUs 

No.  of  PDUs 

No.  of  PDUs 

Location 

Received 

Transmitted 

Out  of  Order 

>  1  sec. 

Grumman 

11859 

11859 

0 

0 

WSMR 

11859 

11859 

0 

0 

Fort  Hood 

11859 

11859 

0 

0 

Fort  Sill 

11859 

11859 

0 

0 
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Table  5.  Stress  Test  Results  (11859  PDUs  Transmitted) 


Link 

Times  Expected  Rate 
(XE.R.) 

Rate  (PDU/sec) 

Ping  Time  (ms) 
Min/Max/Ave 

Number  PDUs 
Received 

Gnimman 

1  X  E.R. 

100 

60/120/61 

11859 

2  X  E.R. 

200 

59/90/68 

11858 

3  X  E.R. 

300 

59/90/64 

11853 

4  X  E.R. 

400 

57/210/79 

11847 

5XE.R. 

500 

57/840/256 

10492 

WSMR 

1  X  E.R. 

100 

59/61/59 

11859 

2XE.R. 

41/61/59 

11858 

3XE.R. 

41/60/45 

11853 

4  X  E.R. 

41/61/58 

5XE.R. 

500 

41/70/56 

11849 

Fort  Hood 

1  X  E.R. 

40/69/59 

11859 

2XE.R. 

37/60/42 

11858 

3  XE.R. 

11853 

4  XE.R. 

38/61/58 

5XE.R. 

500 

37/61/54 

11859 

Fort  Sill 

1  X  E.R. 

30/61/58 

11859 

2  X  E.R. 

30/60/52 

11857 

3  X  E.R. 

300 

30/61/43 

11853 

4XE.R. 

400 

30/60/36 

5  X  E.R. 

500 

30/84/300 

Table  6.  No  Load  Latency  Test  Results 


Source 

Destination 

No.  Packets 

Round-Trip  Time  (ms) 

Minimum 

Maximum 

Average 

Grumman_lndy 

32 

57 

71 

57 

TCAC_Indy 

32 

41 

44 

41 

TCAC_Indy 

Fort  Hood  Indy 

32 

37 

77 

38 

TCAC_Indy 

Indy 

32 

40 

30 
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Table  7.  Loaded  Latency  Test  Results 


Source 

Destination 

Packet 

Rate(sec) 

Packets 

Sent/Rec 

Rounc 

1-Trip  Time  (ms) 

Min 

Max 

Ave 

TCAC_Indy 

Grumman_Indy 

.01 

320/320 

58 

163 

60 

.005 

640/639 

58 

61 

58 

.0025 

1280/1279 

IHBI 

MEM 

58 

.00125 

WBSM 

58 

TCACJndy 

WSMRIndy 

.01 

320/320 

42 

45 

42 

.005 

640/639 

42 

85 

42 

.0025 

960/960 

42 

51 

42 

TCAC_Indy 

Fort  Hood  Indy 

.01 

320/320 

38 

39 

38 

.005 

39 

55 

39 

.0025 

960/960 

38 

76 

39 

.01 

320/320 

31 

33 

31 

.005 

640/639 

31 

33 

31 

.0025 

960/960 

31 

33 

31 

The  results  of  the  network  characterization  tests  indicate  the  ETE  network  should  meet  the  performance 
requirements  of  the  tests  with  adequate  margin. 

The  stress  test  results  indicated  a  potential  problem  with  loss  of  data  under  stressful  situations. 
Appendix  I  documents  a  detailed  analysis  of  this  problem  performed  by  the  JADS  Network  and 
Engineering  team  and  a  field  engineer  fi-om  Netwoik  Equipment  Technologies,  the  developer  and 
manufacturer  of  one  of  the  routers  used  by  JADS  in  their  networks. 

The  local  area  network  (LAN)/wide  area  network  (WAN)  Exchange  (LWX)/Cisco  router  investigation 
had  five  objectives: 

1 .  Verification/validation  of  the  problems  witnessed  by  JADS  Network  and  Engineering 

2 .  Comparison  of  the  performance  gains/losses  of  external  router  configurations 

3 .  Effects  of  altering  internal  software  configuration  (buffers,  hold  queues,  etc.) 

4.  Effects  of  using  a  hybrid  routed/bridged  network 

5 .  Effects  of  a  completely  bridged  network 

The  LANAVAN  Exchange  (LWX)  Release  3.01  is  a  general  purpose  router/bridge  integrated  into  the 
Integrated  Digital  Network  Exchange  (IDNX)  platform.  It  provides  internetwork  connectivity  between 
LANs  over  WANs  through  IDNX/  90,  /70,  /20,  and  /Micro  20  IDNX  nodes.  The  LWX  is  the 
primary  router  used  in  the  ETE  network.  The  investigation  also  evaluated  the  performance  of  two 
versions  of  routers  from  Cisco.  AH  the  routers  evaluated  use  equivalent  software  from  Cisco. 
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Throughout  all  the  tests  the  broadcaster,  a  Silicon  Graphics,  Inc.  (SGI)  Indy  workstation,  used  a  file  that 
consisted  of  11,859  DIS  ESPDUs.  The  SGI  workstation  broadcasted  the  PDUs  on  its  LAN  as  user 
datagram  protocol  (UDP)  packets.  The  LWXs  were  configured  to  forward  these  broadcasts  through 
the  network.  Each  entity  state  PDU  was  144  bytes  in  length.  The  internet  protocol  (IP)  datagram 
produced  was  152  bytes  in  length.  All  this  was  verified  using  a  network  general  sniffer  protocol 
analyzer  on  the  Broadcaster  subnetwork. 

At  the  distant  end,  the  logger,  also  an  SGI  Indy  workstation,  listened  for  UDP  broadcasts  and  coimted 
the  number  received.  The  difference  is  the  number  of  packets  dropped  within  the  network. 

The  primary  results  of  the  investigation  are  as  follows: 

•  The  use  of  UDP  -  an  inherently  unrehable  transport  mechanism  -  is  not  always  a  suitable  choice  of 
transport  for  data  that  needs  a  high  level  of  reliability.  The  transmission  control  protocol  (TCP)  is 
better  suited  for  reliable  transport  since  it  uses  sequencing  and  acknowledgments,  but  at  a  cost  of 
increased  latency  -  which  was  not  tested.  Also,  the  use  of  multicasting  or  unicasting  would  take 
advantage  of  the  fast  switching  capability  of  all  the  routers  tested. 

•  The  use  of  broadcast-based  networking  has  an  adverse  effect  on  the  network.  Routing  this  traffic 
adds  one  additional  layer  of  processing  (especially  when  the  broadcasts  are  process  switched)  and 
creates  multiple  copies  of  each  datagram  in  order  to  forward  it  to  multiple  network  subnets,  thus, 
congesting  the  network  with  broadcast  traffic.  When  routing  broadcast  traffic,  the  network  should 
be  designed  as  flat  as  possible. 

•  There  were  definitive  “break  points”  where  the  processors  could  not  handle  anymore  packets.  This 
was  tme  on  every  platform  tested. 

•  During  the  testing,  we  did  notice  that  there  were  drops  on  the  hold  queue,  missed  buffer  requests, 
and  fallbacks  on  the  interface  buffers.  To  remedy  this  we  added  to  the  hold  queue  length  and 
increased  the  number  of  permanent  big  buffers.  The  actual  number  of  successful  packets  sent  never 
rose  above  the  initial  ceiling.  In  other  words,  the  addition  of  buffers  and  increasing  the  hold  queue 
did  not  affect,  in  any  way,  the  speed  at  which  the  processor  process  switched  the  packets. 

•  It  is  our  best  judgment  that  the  limitation  is  with  the  router’s  processor  handling  UDP  broadcasts. 
With  UDP  broadcast  traffic,  all  packets  are  process  switched.  With  unicast  and  multicast  traffic, 
the  router  is  capable  of  fast  switching  most  of  the  packets.  Routers  gain  efficiencies  when  they  are 
capable  of  caching  routes  for  packets. 

The  investigation  concluded  that  with  our  current  network  configuration  using  routing  between  subnets, 
we  were  limited  to  an  aggregate  of 400  packets  per  second  through  any  of  the  routers.  This  limitation  is 
adequate  for  the  planned  ETE  tests.  If  further  studies  identify  the  requirement  for  an  aggregate 
throughput  in  excess  of  400  packets  per  second,  switching  from  touting  to  bridging  between  the 
subnetworks  would  allow  up  to  800  packets  per  second. 
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3.3  Data  Management  and  Data  Analysis 

Another  potential  concern  or  constraint  for  using  ADS  for  test  and  evaluation  is  the  impact  of  ADS  on 
data  management  and  data  reduction.  In  addition  to  system  under  test  data,  an  ADS  implementation 
must  instrument  the  synthetic  environment  to  collect  data  on  the  environment  and  analyze  these  data  to 
determine  the  impact  of  the  ADS  environment  on  the  system  under  test.  The  JADS  evaluation 
methodology  identifies  several  measures  used  to  evaluate  the  data  management  and  analysis  related 
concerns  and  constraints. 

M  2-2-1-1  Degree  to  which  ADS  nodes  provide  for  collection,  data  entry,  and  quality  checking  of 
pre-  and  post-trial  briefing  data. 

M  2-2-1-2  Adequacy  of  relevant  test  data  storage  at  ADS  nodes. 

Subobjective  2-3-3  Develop  and  access  methodologies  associated  with  data  management  and  analysis 
for  tests  using  ADS. 

3.3.1  Synthetic  Environment  Data  Collection 

The  primary  instrumentation  of  the  ETE  synthetic  environment  are  data  loggers  at  each  node  to  collect 
and  time  stamp  all  PDU  data  transmitted  and  received  at  the  node.  The  ETE  team  planned  to  install 
dedicated  data  loggers  at  each  location  to  ensure  common  data  formats  and  file  formats  for  each  site. 
Early  in  the  JADS  program,  the  planned  approach  for  all  tests  using  DIS  was  to  use  a  logger  application 
available  firom  the  U.S.  Army  Simulation,  Training,  and  Instrumentation  Command  (STRICOM).  The 
testing  of  a  C4ISR  system  such  as  Joint  STARS  required  running  operational  scenarios  over  long 
periods  of  time,  resulting  in  large  (approximately  600,000  PDUs)  data  sets. 

A  limitation  of  the  STRICOM  logger  was  discovered  during  a  line  test  between  TRAC-WSMR  and  the 
TCAC.  The  STRICOM  logger  allocates  256  segments  per  file.  As  the  segments  fill  to  capacity  the 
STRICOM  logger  closes  the  file  and  ceases  recording  information.  A  proposed  solution  to  the  256 
segment  limitation  was  the  use  of  sequential  files.  The  logger  would  recognize  when  a  file  was  meeting 
the  limitation,  close  the  file  and  open  a  new  sequential  file.  However,  there  existed  the  possibihty  that 
information  might  be  lost  during  the  process  of  closing  one  file  and  then  opening  a  sequential  file.  An 
alternative  to  the  STRICOM  logger  was  the  Janus  logger,  an  apphcation  distributed  with  Janus  that 
allowed  the  collection  and  replay  of  PDUs.  However,  the  Janus  logger  was  designed  to  time  stamp  to  a 
one  second  accuracy. 

The  ETE  team  decided  to  develop  a  logger  test  to  examine  the  strengths,  weaknesses,  and  limitations  of 
the  STRICOM  and  Janus  loggers.  This  test  focused  on  two  issues: 

1 .  What  is  the  impact  of  using  sequential  files? 

2.  Is  the  time  stamping  of  the  Janus  logger  sufficiently  accurate  for  analysis? 
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A  test  bed  was  established  in  the  TCAC  consisting  of  an  Janus  system  providing  the  source  of  the 
PDUs,  a  Janus  logger,  a  STRICOM  logger  set  to  a  50  segment  limitation,  and  a  STRICOM  logger  set 
to  a  250  segment  limitation.  The  scenario  was  set  to  produce  approximately  600,000  PDUs  over  a 
two-hour  test. 

The  conclusions  from  this  test  are  as  follows: 

STRICOM  Logger:  Segmentation  at  either  50  or  250  segment  size  is  usable.  The  opening  and  closing 
of  sequential  files  did  not  dismpt  the  recording  of  PDUs.  The  file  sizes  should  be  chosen  to  enhance 
data  sampling  and  analysis.  The  test  imcovered  a  potential  problem  with  the  STRICOM  logger.  During 
one  of  the  runs,  one  of  the  STRICOM  loggers  experienced  a  loss  of  151  PDUs  in  a  single  block. 
Although  we  were  unable  to  identify  the  specific  source  of  the  loss,  we  suspected  that  some  other 
process  commenced  which  placed  a  demand  on  the  processor  resulting  in  the  loss  of  the  PDUs. 

Janus  Logger:  The  Janus  logger  does  not  time  stamp  at  the  required  accuracy  to  allow  analysis  of  PDU 
latency  and  is  therefore  only  useful  for  its  playback  capabilities. 

The  conclusions  of  the  logger  evaluations  led  JADS  to  develop  the  JADS  logger.  The  JADS  logger 
was  designed  with  three  objectives: 

1 .  High  degree  of  time  stamp  accuracy. 

2.  Minimized  processor  load. 

3 .  Flexible  playback  capability 

The  JADS  logger  was  designed  as  two  processes.  The  first  process  is  a  high-priority  process  that  time 
stamps  the  PDU  upon  receipt.  The  second,  a  low-priority  process,  logs  the  PDUs  when  the  processor 
is  not  busy.  This  ensures  an  accurate  time  stamp.  The  JADS  logger  provides  users  with  a  very  high 
degree  of  accuracy  with  respect  to  log  time  (received  time)  of  PDUs  (typically  better  than  1 
millisecond). 

The  JADS  logger  foregoes  graphics  interfaces  to  minimize  process  load.  It  uses  a  simple  command  line 
interface,  and  in  real  time,  displays  the  number  of  PDUs  received  and  the  PDU  rate  each  time  it  writes  a 
block  of  PDUs  (typically  about  500  entity  state  PDUs)  to  disk.  Because  the  logger  has  a  command 
line  interface,  the  user  can  remotely  log  in  (rlogin),  start  the  logger  as  a  background  process  and  log  out 
of  the  workstation  without  terminating  the  logger  application.  This  option  keeps  network  traffic  to  a 
minimum  while  performing  the  logging  function  at  a  remote  location. 

JADS  also  developed  the  JADS  player,  a  playback  capability  that  operates  in  two  modes:  a  speed 
mode  where  the  operator  identifies  a  multiplier  to  control  the  speed  of  the  playback,  and  a  rate  mode 
where  the  operator  designates  the  numbers  of  PDUs  per  second  to  be  played.  Additionally,  in 
conjunction  with  the  JADS  analysis  toolbox,  the  player  can  be  directed  to  start  the  playback  at  any  log 
time. 
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The  JADS  logger/player  meets  all  the  requirements  of  the  ETE  test  and  provides  a  simple  and  reliable 

data  collection  and  data  analysis  tool. 

3.3.2  Synthetic  Environment  Data  Analysis 

In  addition  to  tihe  logger  tools,  JADS  developed  various  analysis  tools  for  analysis  of  the  PDU  data. 

The  tools  have  been  integrated  into  (can  all  be  called  up  from)  a  single  tool,  the  JADS  analysis  toolbox. 

The  toolbox  provides  users  with  a  single  interface  to  the  software  routines  developed  by  JADS.  These 

tools  provide  for  real-time  viewing  of  PDU  data,  and  for  post-test,  quick-look  analyses  using  logged 

PDU  data. 

The  JADS  analysis  toolbox  provides  a  point  and  click  interface  to  the  various  JADS  analysis  routines. 

The  routines  available  from  the  toolbox  menu  are  the  following; 

•  Monitor  -  3-D  Display;  A  graphical  3-dimensional  (3-D)  display  of  up  to  3  entities  that  displays 
latitude,  longitude,  and  altitude  in  real  time  is  provided. 

•  Monitor  -  PDU  Statistics  and/or  PDU  Latency;  The  following  PDU  statistics  are  provided  by  the 
PDU  statistics  display; 

the  total  number  of  PDUs  received, 
the  PDU  (receive)  rate, 
the  number  of  entities  received,  and 
the  number  of  each  type  of  PDU  received. 

A  plot  of  PDU  latency  (received  time  -  PDU  creation  time)  in  real  time  is  also  available. 

•  Analyze  -  Quick-Look;  The  JADS  quick-look  analysis  tool  provides  analysts  with  a  point  and 
click  means  of  obtaining  mission,  PDU,  and  logger  performance  data  visualizations  for  DIS 
exercises.  Visualization  is  provided  for  four  categories  of  data; 

•  Mission  Visualization:  Present  support  is  for  3-D  plots  of  up  to  3  entities,  e.g.,  a  shooter,  target, 
and  missile,  for  either  the  total  mission  or  just  during  the  flyout,  and  either  static  or  animated. 

•  Latency  Data  Visualization:  Plots  of  PDU  latency  {fiom  PDU  creation  to  time  received},  from 
logger  to  logger,  for  all  entities  as  well  as  for  individual  entities  can  be  created.  Also,  a  latency 
statistics  tabulation  is  available  that  enumerates  the  minimum,  maximum,  and  average  latency  for 
each  entity,  each  test,  and  each  logger. 

•  PDU  Performance  Visualization:  Plots  of  the  number  of  PDUs  received  per  second  of  PDU 
time  and  the  number  of  PDUs  per  second  of  log  time  for  each  entity  as  well  as  for  individual 
entities  are  created.  Also,  a  PDU  statistics  tabulation  is  available  that  enumerates  the  number  of 
PDUs,  the  number  of  duplicate  PDUs,  and  the  number  of  PDU  dropouts,  for  each  entity,  each 
test,  and  each  logger. 

•  Logger  Performance  Visualization:  Plots  of  log  time  difference  between  successive  received 
PDUs  for  each  entity  as  well  as  for  individual  entities  are  created. 
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The  quick-look  analysis  tool  allows  the  user  to  select  multiple  sets  of  trials,  loggers,  and  entities  and 
then  sequentially  presents  the  selected  plot  data  for  review,  formatting,  and/or  printing.  Thus,  a 
summary  analysis  package  can  be  prepared  in  a  short  time.  The  quick-look  analysis  tool  is  used  in 
conjimction  with  the  JADS  logger  which  records  (logs)  DIS  PDUs  during  an  exercise. 

•  Analyze  -  General  Plots:  The  JADS  general  plots  tool  provides  for  generalized  plotting  of  data  from 
a  file.  Plots  of  any  of  the  supported  PDU  parameters  (Entity  ID  [identification].  Log  Time,  PDU 
Time,  Latitude,  Longitude,  or  Altitude  versus  another)  may  be  made. 

•  Dump  -  Select  Entity  Parameters:  Dumps  any  to  the  following  selected  parameters  into  a  text  file 
from  a  log  file: 


Entity  ID 

PDU  Time  (milliseconds) 

PDU  Timestamp  (milliseconds  -  using  all  32  bits  with  each  bit  as  one  millisecond) 
Latitude  (degree) 

Longitude  (degree) 

Altitude  (feet) 

North  Velocity  (feet/second 
East  Velocity  (feet/second) 

Down  Velocity  (feet/second) 

X  (meters,  geocentric) 

Y  (meters,  geocentric) 

Z  (meters,  geocentric) 

X  Velocity  (meter/second) 

Y  Velocity  (meter/second) 

Z  Velocity  (meter/second) 

X  Acceleration  (meter/second/second) 

Y  Acceleration  (meter/second/second) 

Z  Acceleration  (meter/second/second) 

Phi  (radians) 

Psi  (radians) 

Theta  (radians) 

Pitch  (radians) 

Roll  (radians) 

Yaw  (radians) 

Pitch  Rate  (radians/second) 

Roll  Rate  (radians/second) 

Yaw  Rate  (radians/second) 

UTM  Northing  (meters) 

UTM  Easting  (meters) 

UTM  Zone 
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IXimp  -  Split  File:  Splits  a  log  file  into  a  smaller  file  log  file  based  on  user  provided  log  start  and 
stop  time. 
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•  Dump  -  Count  PDUs:  Provides  a  tabulation  summarizing  the  following: 

Nrunber  of  PDUs, 

Niunber  of  entity  state  PDUs, 

Number  of  data  PDUs, 

Number  of  detonation  PDUs, 

Number  of  fire  PDUs, 

Number  of  start  PDUs,  and 
Number  of  stop  PDUs. 

•  Dump  -  Display  Time:  Provides  a  tabulation  that  displays  log  time  and  PDU  time  in  the  following 
formats: 

Log  timestamp  (seconds  since  1970  and  microseconds) 

Log  time  (milliseconds  since  midnight) 

Log  time  (hh:mm:ss.sss) 

PDU  timestamp  (milliseconds  past  the  hour) 

PDU  time  (milliseconds  since  midnight) 

Delta  PDU  time  (time  between  PDUs) 

Latency  (log  time  -  PDU  time  in  milliseconds) 

•  Dump  -  Moving  Entities:  Provides  a  listing  for  each  minute  of  log  time  the  following  data  are 
provided: 

Starting  log  time 
Ending  log  time 
Starting  PDU  time 
Ending  PDU  time 
Number  of  PDUs 
Number  of  movements 
Number  of  entities  that  moved 

These  tools  were  developed  using  a  foundation  of  C,  C++,  Motif,  X-Windows,  and  gnuplot  and  are 
transportable  to  a  variety  of  machines. 

The  very  large  data  sets  and  the  large  numbers  of  entities  associated  with  the  ETE  tests  required 
significant  modifications  to  the  quick-look  and  real-time  analysis  software. 

The  major  modifications  were  the  following: 

•  Entity  Selection:  For  each  desired  analysis  display,  the  quick-look  program  provides  the  analyst 
with  the  capability  to  select  a  set  of  tests  (for  a  given  mission/day),  a  set  of  log  files  and,  for  some 
analyses,  a  set  of  entities.  The  desired  tabulations  or  plots  are  displayed  sequentially  for  the 
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selected  tests,  logs,  and  entities,  and  with  each  display  the  user  is  given  the  option  to  vary  the 
format,  print,  or  display  a  histogram.  This  ability  to  select  a  set  of  data  for  which  given  analysis 
displays  are  desired  greatly  facihtates  processing  missions  that  have  many  tests  and  many  loggers. 
Previously,  the  quick-look  program  read  through  each  selected  log  file  to  find  all  of  the  different 
entities  that  were  used  so  they  could  be  displayed  to  the  analyst  for  selection.  This  worked  fine 
when  the  files  were  kilobytes  in  size  and  the  numbers  of  entities  were  small,  i.e.,  less  than  10. 
However,  for  the  ETE  tests,  the  files  approached  100  megabytes  in  size,  and  the  numbers  of  entities 
were  up  to  10,000.  Thus,  the  previous  program  would  have  to  read  100  megabytes,  10,000  times 
to  make  sure  all  of  the  entities  were  identified.  This  would  have  taken  hours  before  the  available 
entities  m  the  selected  logs  could  be  displayed  to  the  user  for  selection.  Even  reading  through  the 
very  large  file  once  took  several  minutes.  Thus,  an  alternative  approach  was  selected. 

The  selected  approach  was  to  process  the  log  files  once  for  the  entities  (and  for  the  start  and  stop 
PDU  and  log  times  -  other  data  needed  by  the  analysis  programs  that  would  have  required  reading 
through  the  entire  file  each  time)  and  to  save  these  data  in  a  companion  .stats  file.  Thus,  estabhshing 
the  entities  within  a  log  file  (or  the  earliest  and  latest  PDU  or  log  time)  was  a  simple  matter  of 
reading  the  very  short  companion  .stats  file. 

•  Entities  Selection:  Again,  due  to  the  large  number  of  entities,  a  method  was  needed  whereby  the 
identification  of  entities  would  not  be  a  long,  long  Hst  of  integers.  Thus,  the  handling  of  selected 
entities  was  modified  so  that  the  user  is  shown  and  can  identify  entities  using  the  following  example 
string  notation 

1-50,  501-600,  9001-9050 

This  string  identifies  200  entities  that  the  analyst  wants  included  in  the  analysis.  Similarly,  die 
notation  is  used  in  the  .stats  files  to  tell  the  analyst  (and  the  software)  which  entities  are  included  in 
the  log  file.  It  greatly  reduces  the  task  of  identifying  entities,  albeit  with  a  minor  increase  in  software 
workload. 

•  Data  Calculations:  Previously,  the  quick-look  program  read  the  PDU  data  needed  for  calculation 
into  data  arrays.  The  array  sizes  for  the  System  Integration  Test  were  less  than  5,000,  i.e.,  the 
number  of  PDUs  for  any  given  test  were  less  than  5,000.  The  data  included  entity  number,  log  time, 
PDU  time,  latitude,  longitude,  and  altitude.  Thus,  the  total  array  storage  for  a  given  test  logger  was 
approximately 

5000  pdus  *  6  parameters/pdu  *  8  b3des  /  parameter  =  240,000  bytes. 

For  ETE,  the  number  of  PDUs  exceeded  400,000.  Thus,  the  memory  that  would  have  been 
required  to  keep  the  data  in  memory  would  have  exceeded  19  megabytes  for  a  given  test  logger. 
Given  aU  the  other  memory  requirements  of  the  quick-look  analysis  program,  this  was  prohibitive. 
Thus,  it  was  decided  to  change  all  of  the  data  processing  routines  to  accompHsh  their  tasks  without 
using  data  arrays,  i.e.,  read  the  minimum  data  required  fi:om  a  file  to  accomphsh  a  calculation  (at 
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most  this  meant  two  or  three  PDUs),  and  then  write  the  results  to  another  file  for  further  processing 
or  for  display.  The  result  is  software  insensitive  to  the  size  of  the  data  files  insofar  as  calculations  are 
concerned. 
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•  Entity  Number:  For  previous  tests,  the  entity  identification  was  maintained  as  a  unique  number 
among  all  the  sites,  i.e.,  there  was  only  one  entity  3.  For  EXE,  as  would  be  expected  in  a  large- 
scale  DIS  exercise,  the  entity  identification  was  not  unique.  The  entity  identification  data,  i.e.,  the 
site  ID,  host  ID,  and  entity  ID  combination  was  unique,  so  that  unique  entity  numbers  could  be 
established  based  on  all  three  fields.  This  was  accomplished  for  both  quick-look  and  real-time 
analysis  programs. 

3.3.3  Data  Management  and  Analysis  Summary 

The  primary  challenge  of  an  ADS  test  of  a  C4ISR  system  is  the  potential  for  a  large  ADS  synthetic 
environment  data  sets  and  the  use  of  large  numbers  of  entities.  During  Phase  1,  JADS  began  to  gain 
insight  into  some  of  the  problems  with  data  management  and  data  analysis;  however,  the  development 
and  refinement  of  data  management  and  data  analysis  tools  will  continue  through  fixture  phases  of  the 
ETE  test. 

An  equally  important  area  for  investigation  in  fixture  phases  will  be  the  impact  on  system(s)  under  test 
data  management  and  data  analysis  tools.  The  ADS  synthetic  environment  provides  the  capability  to 
test  multiple  systems  simultaneously,  both  individually  and  to  determine  impacts  of  one  system  upon 
another  system.  The  nature  of  C4ISR  will  require  such  tests  to  be  run  over  longer  periods  of  time  and 
will  produce  large  data  sets  requiring  improved  data  management  and  analysis  techniques. 
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4.0  Lessons  Learned 


4.1  Technical  Lessons  Learned 

4.1.1  Data  Transport  Reliability  Considerations 

The  use  of  user  datagram  protocol  (UDP)  -  an  inherently  unreliable  transport  mechanism  -  is  not  always 
a  suitable  choice  of  transport  for  data  that  needs  a  high  level  of  reliability.  Routers  and  bridges  used  to 
connect  subnetworks  are  the  primary  source  of  lost  data  in  networks  using  UDP.  The  use  of  UDP 
forces  routers  to  inspect  each  packet  since  it  was  a  broadcast  and  forward  it  onto  each  interface.  This 
activity  is  known  as  process  switching.  Since  every  packet  sent  is  process  switched,  there  is  a  limit  to 
the  number  of  packets  successfully  received  when  a  node  floods  the  network.  Testing  of  several  routers 
confirmed  there  are  definitive  “break  points”  where  the  router  processors  carmot  handle  additional 
packets. 

Routing  UDP  traffic  adds  one  additional  layer  of  processing  (especially  when  the  broadcasts  are 
process  switched)  and  creates  multiple  copies  of  each  datagram  in  order  to  forward  it  to  multiple 
network  subnets,  thus,  congesting  the  network  with  broadcast  traffic.  When  routing  broadcast  traffic, 
the  network  should  be  designed  as  flat  as  possible.  Additionally,  any  routers  used  should  be  tested  to 
determine  their  specific  break  point. 

Bridging  UDP  traffic  precludes  the  need  to  process  switch  each  packet  and  allows  the  routers  to  use 
multicasting  or  unicasting  techniques  and  take  advantage  of  faster  switching  capabihty.  This  increases 
the  aggregate  number  of  packets  a  router  can  reliably  transfer. 

If  reliable  transfer  of  data  is  required,  the  transmission  control  protocol  (TCP)  is  better  suited  for  reliable 
transport  since  it  uses  sequencing  and  acknowledgments,  but  at  a  cost  of  increased  latency. 

4.2  Programmatic  Lessons  Learned 

4.2.1  Value  of  Systems  Engineering  Process 

The  development  of  an  ADS  synthetic  environment  for  test  and  evaluation  is  a  challenging  activity.  The 
developer  must  integrate  the  system(s)  under  test  technology,  networking  technology,  simulation 
technology,  and  instrumentation  technology  into  an  environment.  The  activity  requires  a  multifunctional 
team  of  personnel  to  derive  the  functional  and  performance  requirements,  acquire  and/or  develop  the 
components,  and  integrate  the  environment. 

The  systems  engineering  process  is  used  throughout  the  services  and  industry  as  an  integral  process  in 
die  development  of  a  system.  The  process  is  reiterated  during  each  acquisition  phase,  and  whenever  a 
technical  change  is  initiated  or  needed,  to  provide  progressive  definition  of  the  system.  From  the 
beginning  of  the  JADS  Joint  Feasibility  Study  through  Phase  1,  the  JADS  ETE  team  has  used  the 
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process  to  define  and  refine  the  ADS  synthetic  environment  and  the  components  in  the  environment. 
Figure  8  is  the  Defense  Systems  Management  College’s  depiction  of  this  process. 
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Figure  8.  Systems  Engineering  Process 

Requirements  Analysis:  The  customer’s  requirements  are  derived/defined/refined  and  integrated  in 
terms  of  quantifiable  characteristics  and  tasks  that  the  environment  must  satisfy.  For  each  requirement, 
absoluteness,  relative  priority,  and  relationship  to  other  requirements  are  identified.  The  impact  of  the 
requirements  is  analyzed  in  terms  of  mission,  environment,  constraints,  and  measures  of  performance. 
Impacts  are  continually  examined  for  validity,  consistency,  desirability,  and  attainability.  The  outyut  of 
this  analysis  is  the  functional  (what)  and  performance  (how  well)  requirements  for  the  environment. 


Functional  Analysis/Allocation:  Through  a  functional  decomposition  all  primary  environment  functions 
and  subfunctions  are  progressively  derived/defined/refined  to  determine  the  actions/tasks  an  item  must 
perform  to  satisfy  customer  needs.  Decomposition  continues  until  all  performance  requirements  are 
allocated  and  aU  functional  relationships  are  determined. 
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Synthesis;  Allocated  requirements  are  satisfied  through  a  bottom  up,  progressively  integrated 
design/synthesis  of  process  and  product  alternative  solutions.  Internal  and  external  interfaces  are 
analyzed,  trade-offs  made,  and  a  set  of  design  requirements  are  established.  As  design  requirements 
are  estabhshed,  verification  ensures  that  all  associated  functional  and  physical  interfaces  and  functional 
and  performance  requirements  are  satisfied.  The  resulting  set  of  design  requirements  provides  the  basis 
for  selecting,  developing,  and  integrating  the  components  of  the  ADS  environment. 

System  Analysis  and  Control:  Throughout  the  requirements  analysis,  fijnctional  analysis/allocation,  and 
synthesis  subprocesses,  cost,  schedule,  performance  and  risk  are  balanced  to  provide  an  environment 
that  is  affordable,  suitable,  and  effective.  A  variety  of  analysis  and  control  tools  are  available  to  evaluate 
design  capabilities,  to  determine  progress  in  satisfying  technical  requirements  and  technical  program 
objectives,  to  formulate  and  evaluate  alternative  designs/courses  of  actions,  and  to  evolve  the 
environment  to  satisfy  customer  needs. 

JADS  has  learned  a  key  lesson:  ADS  is  not,  as  some  would  claim,  a  “plug  and  play”  technology. 
Developing  an  ADS  environment  requires  a  disciplined  process  to  integrate  the  various  technologies  and 
functional  disciplines  into  a  usable  whole.  JADS  believes  the  systems  engineering  process  is  a  proven 
methodology  which  can  be  successfully  applied  to  this  challenge. 
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5.0  Future  Activities 


Phase  2  of  the  End-to-End  Test  consists  of  planning,  preparing,  and  conducting  a  developmental  test 
activity  using  some  of  the  components  developed  in  Phase  1  and  planning,  preparing  and  conducting  an 
operational  test  activity. 

5.1  Scenario  Development 

Each  test  activity  requires  the  development  of  one  or  more  scenarios  designed  to  meet  the  objectives  of 
the  specific  test  activity.  Scenarios  developed  for  developmental  testing  are  based  on  the  system 
specifications  of  the  system  under  test  and  require  careful  analysis  and  testing  to  ensure  they  meet  the 
objectives  of  the  test.  Scenarios  developed  for  operational  testing  are  based  on  a  large  scale  scenario 
and  are  focused  more  on  operational  reahsm  rather  than  specification  accuracy.  JADS  will  develop  2 
scenarios  for  verification  and  validation,  12  scenerios  for  developmental  testing,  and  TRAC-WSMR  will 
make  up  to  nine  scenarios  for  operational  testing.  Operational  test  scenarios  will  be  based  on  an 
expanded  version  of  a  U.S.  Army  Test  and  Experimentation  Command  (TEXCOM)  scenario,  The 
Road  to  War,  that  TEXCOM  uses  to  test  components  of  the  Army  Tactical  Command  and  Control 
System.  The  overall  scenario  is  128  hours  and  JADS  has  selected  nine  6-hour  vignettes  firom  the 
scenario  to  be  implemented  in  Janus. 

5.2  Terrain  and  Feature  Database  Development 

The  SAR  simulation  developed  in  Phase  1  requires  a  highly  detailed  map  of  the  terrain  and  features  on 
the  terrain  to  develop  high  quahty  images.  The  basic  capabilities  of  the  digital  terrain  elevation  data 
(DTED)  and  digital  feature  analysis  data  (DFAD)  databases  developed  by  the  National  Imaging  and 
Mapping  Agency  have  neither  the  quahty  nor  the  resolution  to  meet  the  requirements  of  the  simulation. 
JADS  will  apply  Geographical  Information  System  (GIS)  technology  to  the  products  to  correct  errors 
and  enhance  the  data  using  information  on  1:50,000  and  1:100,000  maps.  The  resulting  databases  will 
be  used  both  for  the  SAR  simulation  and  to  provide  higher  quality  terrain  maps  for  Janus. 

53  Verification,  Vafidation,  and  Accreditation  (W&A) 

W&A  are  key  aspects  of  the  Phase  2  effort.  A  verification  and  vahdation  plan  was  developed  during 
Phase  1  which  apphed  the  principles  of  the  DIS  Nine-Step  W&A  Process  and  the  DoD  W&A 
Process  into  a  W&A  process  for  JADS  ETE.  In  Phase  2,  this  plan  will  be  executed,  resulting  in  a 
synthetic  environment  accredited  for  use  in  the  JADS  ETE  operational  test  at  the  end  of  Phase  2. 

5.4  Developmental  Test 

Phase  2  developmental  testing  will  be  conducted  in  conjunction  with  testing  of  system  upgrades  by 
Northrop  Grumman.  Northrop  Grumman  is  preparing  an  update  to  the  E-8C  software  which  includes 
improvements  to  the  automatic  tracker  function  of  the  operations  and  control  subsystem.  Previous 
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testing  of  the  tracker  has  been  performed  with  medium  fidelity  simulation  and  multiple  flight  tests. 
Northrop  Grurnman  has  provided  specifications  for  12  scenarios  which  are  designed  to  test  all  the 
tracker  requirements.  JADS  will  implement  these  scenarios  in  Janus  and  provide  log  files  of  the 
scenarios  to  Northrop  Grumman.  Northrop  Grumman  will  use  the  log  files  and  the  JADS  player  tool 
developed  in  Phase  1  to  test  the  automatic  tracker.  JADS  will  observe  these  tests  and  collect 
information  from  Northrop  Grurnman  relative  to  the  utility  of  the  capability. 

5.5  Operational  Test 

Phase  2  will  culminate  with  an  operational  test  which  uses  the  entire  ETE  synthetic  environment  and 
includes  constmctive,  virtual,  and  live  participants.  The  operational  test  is  designed  to  evaluated  the 
utihty  of  the  environment  to  support  early  operational  testing  or  assessments  using  a  laboratory 
environment.  Janus  will  be  used  to  provide  constructive  targets  for  the  Joint  STARS  sensor  being 
simulated  by  VSTARS.  Radar  reports  from  VSTARS  will  be  sent  to  E-8C  workstations  in  a  Northrop 
Grumman  laboratory  and  will  be  sent  to  a  ground  station  module  (GSM)  located  at  Fort  Hood,  Texas, 
using  the  SCDL  interface.  The  GSM  will  be  in  support  of  a  subset  of  the  analysis  and  control  element 
(ACE)  who  will  merge  Joint  STARS  data  with  other  intelUgence  sources  to  analyze  the  battlefield  and  to 
nominate  targets  for  the  Army  Tactical  Missile  System  (ATACMS).  These  nominations  will  be  sent  to 
the  Depth  and  Simultaneous  Attack  Battle  Lab  at  Fort  Sill,  Oklahoma,  where  doctrinally  correct  artillery 
command  and  control  will  be  simulated  and  eventually  a  simulated  missile  will  be  fired  at  the  target. 
Messages  describing  the  firing  and  detonation  of  the  missile  wUl  be  sent  back  to  Janus  for  assessment  of 
damage  on  the  battlefield.  Data  will  be  collected  which  supports  the  evaluation  of  operational  measures 
of  effectiveness  to  allow  JADS  to  evaluate  the  utility  of  the  environment  to  support  operational  testing. 
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1  Purpose 


This  document  is  intended  to  report  on  the  results  of  a  study  conducted  to  determine  and  evaluate 
candidate  architectures  for  the  RADAR  Processor  Simidation  (RPS)  for  the  JOINT-STARS  system, 
for  the  purposes  of  integrating  JOINT-STARS  into  a  Joint  Advanced  Distributed  Simulation  (JADS) 
environment.  A  typical  JADS  environment  is  shown  in  Figure  1-1. 


Figure  1-1  Typical  JADS  Environment 


The  general  concept  of  operation  for  the  JSTARS  system  within  such  an  environment  is  as  follows: 

•  The  JSTARS  aircraft  will  fly  over  a  government  controlled  facility  (such  as  Ft.  Irwin) 

•  A  small  area  will  contain  controlled  targets,  tanks,  tmcks,  etc. 

•  A  target^war  simulation  such  as  JANUS  will  be  operating  at  a  government  faciUty  such  as  White 
Sands  Missile  Range  (WSMR)  generating  virtual  targets  and  issuing  Protocol  Data  Units 
(PDUs)  on  the  Distributed  Interactive  Simulation  (DIS)  network 

•  The  RPS  will  receive  the  virtual  target  information,  fix)m  the  DIS  network  via  entity  state  PDUs 
and  supply  virtual  target  RADAR  reports  combined  with  the  hve  target  RADAR  reports 

The  block  diagram  for  the  JSTARS  system  is  shown  in  Figure  1-2.  The  JSTARS  system  consist  of  five 
subsystems  the  Operations  and  Control  Subsystem,  the  Data  Link  Subsystem,  the  Communications 
Subsystem,  the  RADAR  Subsystem,  and  the  Aircraft  Subsystem.  The  focus  of  this  study  will  be  on  the 
RADAR  Subsystem  which  is  shown  in  more  detail  in  Figure  1-3. 
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Figure  1-2  JSTARS  System  Block  Diagram 


Figure  1-3  RADAR  Subsystem  Hardware  Block  Diagram 

The  RADAR  subsystem  includes  a  RADAR  Data  Processor  (RDP)  which  is  a  VAX  866  General 
Purpose  Computer  (GPC),  a  RADAR  Sensor  and  Programmable  Signal  Processors  (PSPs).  The  RDP  is 
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used  to  control  the  sensor  and  process  data  received  from  by  the  sensor.  The  RADAR  sensor  is 
comprised  of  the  Line  Replaceable  Units  (LRUs)  required  to  position  the  Antenna,  generate  the  Radio 
Frequency  (RF)  signal,  amplify  and  radiate  the  RF  signal,  receive  the  reflected  signal  and  process  the 
signal  to  a  video  level.  The  video  data  in  the  form  of  In-Phase  and  Quadrature  (I&Q)  data  is  further 
processed  for  target  detections  in  the  PSPs  and  RDP. 

Some  candidate  architectures  presented  in  this  report  will  use  a  computer  designated  as  the  "Spare"  GPC. 
This  GPC  is  contained  in  the  O&C  Subsystem  which  is  shown  in  Figure  1-4.  The  "Spare"  GPC  has 
access  to  the  same  data  buses  as  the  RDP,  which  makes  it  a  prime  candidate  for  performing  functions 
similar  to  the  RDP. 


Data  Link  Data  Bus  (DDB) 


FLIGHT  MANAGB^fiMT  BUS  (FMB)  I 


Figure  1-4  O&C  Subsystem  Hardware  Block  Diagram 

The  RADAR  processing  functional  allocation  to  the  hardware  components  is  shown  in 
Figure  1-5. 
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Figure  1-5  RADAR  Processing  Block  Diagram 


2  Applicable  Documents 

The  following  is  a  list  of  the  applicable  documents: 


Document  Name  Date  of  Issue  Revision 

Engineering  Services  Task  (EST)  Statement  of  21  December  1992 
Work  E-8C  RADAR  Processor  Simulation 
System  Specification  For  Joint  Surveillance 
Target  Attack  RADAR  System  AN/US Y-TBD 
(JOINT  STARS) 

(U)  Prime  Item  Development  Specification  For  12  June  1991 
RADAR  Subsystem  AN/APY-(TBD)  For  Joint 
Surveillance  Target  Attack  RADAR  System 
(JOINT  STARS) 
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3  Trade  Study  Candidate  Definitions 

3.1  Candidate  Descriptions 

The  description  of  each  candidate  included  in  the  study  is  provided  in  the  following  paragraphs.  These 
descriptions  are  conceptual  in  nature  and  are  not  to  be  considered  design  requirement  definitions. 

3.1.1  Candidate  One  Description 

This  candidate  was  conceived  on  tiie  basic  premise  of  minimizing  message  traffic  flow  across  hardware 
buses  and  to  contain  the  simulation  in  the  same  processing  unit  as  the  existing  MTI  processing. 

3. 1.1. 1  Candidate  One  Block  Diagram 

The  fimctional  block  diagram  for  candidate  number  one  is  shown  in  Figure  3-1  the  added  functionality  is 
shown  as  shaded.  This  candidate  requires  that  all  new  functionality  be  placed  in  the  present  RADAR 
Data  Processor  (RDP)  and  therefore  must  meet  the  present  RDP  memory  and  CPU  loading 
requirements. 
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Figure  3-1  Functional  Block  Diagram  Candidate  One 


3. 1.1. 2  Candidate  One  Interface  Requirements 

This  candidate  will  interface  with  the  DIS  network  through  the  PDU  interface  module  which  wiU  reside 
in  the  RDP.  This  will  be  done  completely  by  software  and  requires  no  additional  hardware  interface. 
The  RPS  will  interface  with  the  existing  RADAR  sensor  control  (RSC)  and  signal  processing 
(POSTPROC)  functions  via  global  common  areas  in  the  RDP  memory  and  thus  does  not  require  any 
hardware  interface  bus  traffic. 

3 . 1 . 1.2. 1  DIS  Network  Interface  Processing 

The  candidate  processor  will  receive  the  entity  state  information  from  the  DIS  and  perform  the 
necessary  coordinate  transformations.  This  information  will  be  provided  to  the  SAR  simulator  and  the 
MTI  simulator  as  required,  via  the  Target  data  base  process. 

3. 1.1. 2.2  RPS  Control  Interface  Requirements 
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The  candidate  one  control  processing  will  perform  the  overall  function  of  controlling  the  PDU,  SAR 
simulator  and  the  MTI  simulator  and  as  such  will  be  required  to  interface  on  a  message  level  with  die 
existing  RDP  functions.  The  RPS  control  program  will  contain  the  capability  to  receive  and  process  the 
following  messages;  PSP  Parameter  messages,  and  the  MTI  report  message.  The  RADAR  processing 
functional  allocation  to  the  hardware  components  is  shown  in  Figure  3-2  with  the  RPS  virtual  target 
injection  points  shown  as  shaded. 

PSP  NODE  1 


Figure  3-2  RADAR  Processing  Block  Diagram 


3 . 1 . 1 .2.3  SAR  Simulator  Interface  Requirements 

The  SAR  simulator  must  receive  navigation,  target,  terrain  and  cultural  features  data  from  the  RPS 
control  processor.  This  data  wiU  contain  the  aircraft  platform  position  as  a  function  of  time  as  well  as 
target  types,  vegetation  type,  cultural  features  (such  as  buildings)  and  tenain  elevation.  ( The  terrain  data 
will  be  obtained  from  a  disk  file  containing  the  predefined  exercise  database.) 

3.1.1 .2.4  MTI  Simulator  Interface  Requirements 

The  MTI  simulator  will  receive  moving  target  information  from  the  RPS  control  processor.  This 
information  will  contain  target  type,  target  position  in  TCS  coordinates  and  target  velocity.  The  Mil 
simulator  will  generate  target  detection  reports  which  contain  target  type,  target  velocity,  target  range, 
and  target  cone  angle.  These  interface  requirements  are  shown  in  Figure  3-3. 
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Figure  3-3  MTI  Simulator  Software  Interface  Requirements 

3. 1.1. 3  Candidate  One  Hardware  Requirements 

This  candidate  resides  in  the  existing  RDP  and  requires  no  additional  hardware  or  any  modification  to 
tile  existing  hardware. 

3. 1.1. 4  Candidate  One  Timeline  Requirements 

This  candidate  resides  in  the  present  RDP  which  is  a  Militarized  VAX  866  and  as  such  must  perform  in 
the  existing  memory  and  CPU  loading  environment.  The  present  design  utilizes  3.6  Megabj^s  of  it's 
existing  64  Megabytes  of  global  common  memory  and  78.1\%  of  the  CPU  is  loaded. 

3 . 1 . 1 .4. 1  PDU  Timeline  Requirements 

The  relative  time  line  requirements,  or  sequence  of  events,  for  the  PDU  interface  unit  is  shown  in 
Figure3-4  and  3-5. 
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3 . 1 . 1 .4.2  SAR  Simulator  Timeline  Requirements 

The  relative  timeline  for  the  present  SAR  processing  is  shown  in  Figure  34.  The  SAR  simulator  must 
operate  within  the  bounds  of  this  time  Une. 
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Figure  34  SAR  Timeline 


3.1.1 .4.3  MTI  Simulator  Timeline  Requirements 

The  relative  timeline  diagram  for  the  MTI  simulator  for  candidate  number  one  is  shown  in  Figure  3-5. 
The  figure  shows  the  relative  timeline  requirements  for  each  process  required  to  perform  the  simulation. 


Figure  3-5  MTI  Timeline 
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3. 1.1. 5  Candidate  One  Software  Requirements 

The  following  software  functions  must  be  developed  for  this  candidate  ;  DIS  netwoik  interface,  RPS 
control,  Dead  reckoning  processing,  SAR  simulator,  MTI  simulator  and  report  processing. 

3 . 1 . 1 .5 . 1  RPS  Control  Software  Requirements 

The  RPS  control  software  will  be  required  to  perform  the  simulation  initialization,  event  time  line  control, 
simulator  control,  simulation  shut  down  and  error  handling. 

3.1. 1.5.2  PDU  Software  Requirements 

The  PDU  software  will  perform  all  interface  functions  required  to  send,  receive  and  decode  entity  state 
messages  received  on  the  DIS  network.  The  PDU  software  will  also  be  required  to  perform  all 
necessary  coordinate  conversions  and  target  information  updating  (dead  reckoning).  The  PDU  software 
will  be  divided  into  two  distinct  components,  the  DIS  network  interface  and  the  Target  data  base 
process.  The  DIS  network  interface  will  be  hosted  on  a  Unix  based  workstation,  which  will  have  the 
necessary  software  to  interface  over  a  LAN  to  an  RF  data  hnk.  The  Target  data  base  process  will  be 
hosted  in  the  same  processor  as  the  MTI  simulator  and  will  also  interface  with  an  RF  Data  link.  The 
processing  flow  diagram  for  the  PDU  process  is  shown  in  Figure  3-6. 


Figure  3-6  Functional  Block  Diagram  PDU  Processing 
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3. 1 . 1 .5.3  SAR  Simulator  Software  Requirements 


The  SAR  simulation  will  receive  terrain,  target  and  otiier  entity  state  information  and  perform  the 
iunctions  required  to  generate  a  proper  JOINT  STARS  SAR  image.  The  SAR  simulator  will  format  the 
image  information  into  the  proper  JOINT  STARS  format  for  transmittal  over  the  Programmable  Signal 
Processor  (PSP)  LAN  to  the  RDP.  The  software  functional  flow  for  the  SAR  processing  for  candidate 
one  is  shown  in  Figure  3-7. 
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Figure  3-7  SAR  Functional  Software  Flow  Diagram  Candidate  One 
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3.1.1 .5.4  MTI  Simulator  Software  Requirements 


The  MTI  simulator  will  receive  target  entity  state  messages  firom  the  RPS  control  process  and  perform 
the  necessary  functions  to  emulate  the  JOINT  STARS  MTI  signal  processing.  The  simulation  will  be 
performed  on  a  dwell  basis.  The  software  functional  flow  for  die  MTI  processing  for  candidate  one  is 
shown  in  Figure  3-8. 
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Figure  3-8  Functional  Software  Flow  Diagram  Candidate  One 
3.1.2  Candidate  Two  Description 

This  candidate  was  conceived  with  the  idea  of  minimizing  the  impact  to  the  present  processing  by 
isolating  the  new  functionality  in  an  independent  processor.  These  would  require  that  the  functionality  of 
the  spare  General  Purpose  Computer  (GPC)  be  replaced  for  the  exercise  period. 

3. 1.2. 1  Candidate  Two  Block  Diagram 

The  functional  block  diagram  for  candidate  number  two  is  shown  in  Figure  3-9  the  added  functionality  is 
shown  as  shaded.  This  candidate  requires  that  the  majority  of  new  functionality  be  placed  in  the 
present  spare  General  Purpose  Computer.  Some  control  functions  will  reside  in  the  present  RDP  as 
shown  in  the  figure. 


Figure  3-9  Functional  Block  Diagram  Candidate  Two 


3. 1.2.2  Candidate  Two  Interface  Requirements 


This  candidate  will  interface  with  the  DIS  network  through  the  target  data  base  module  which  will  reside 
in  the  Spare  GPC.  This  will  be  done  via  a  LAN  interface.  The  RPS  will  interface  with  the  existing 
RADAR  sensor  control  (RSC)  and  signal  processing  (POSTPROC)  functions  via  the  PSP  and  OWS 
LAN  interfaces  using  message  stmctures  which  have  been  developed  for  communication  with  the  PSPs 
and  CDPs. 

3. 1 .2.2. 1  DIS  Network  Interface  Processing 

The  candidate  processor  will  receive  the  entity  state  information  from  the  DIS  and  perform  the 
necessary  coordinate  transformations.  This  information  will  be  provided  to  the  SAR  simulator  and  the 
MTI  simulator  as  required,  via  the  Target  data  base  process. 

3.1. 2.2.2  RPS  Control  Interface  Requirements 

The  candidate  two  control  processing  will  perform  the  overall  function  of  controlling  the  PDU,  SAR 
simulator  and  the  MTI  simulator  and  as  such  will  be  required  to  interface  on  a  message  level  with  the 
existing  RDP  functions  on  the  OWS  LAN  interface.  The  RPS  control  program  will  contain  the 
capability  to  receive  and  process  the  following  messages:  PSP  Parameter  messages,  and  the  MTI  report 
message. 

3 . 1 .2.2.3  SAR  Simulator  Interface  Requirements 

The  SAR  simulator  must  receive  navigation  and  target  data  from  the  RPS  control  processor.  This  data 
will  contain  the  aircraft  platform  position  as  a  function  of  time  as  well  as  target  types  and  orientation. 
The  SAR  simulator  will  maintain  a  data  base  of  hypsographic  and  cartographic  data  required  to  develop 
the  SAR  image. 

3.1.2.2.4  MTI  Simulator  Interface  Requirements 

The  MTI  simulator  will  receive  moving  target  information  from  the  RPS  control  processor.  This 
information  will  contain  target  type,  target  position  in  TCS  coordinates  and  target  velocity.  The  MTI 
simulator  will  generate  target  detection  reports  which  contain  target  type,  target  velocity,  target  range, 
and  target  cone  angle. 

3. 1.2. 3  Candidate  Two  Hardware  Requirements 

This  candidate  resides  in  the  existing  spare  GPC  and  requires  no  additional  hardware  but  will  cause  the 
spare  GPC  to  be  reconfigured  to  the  RPS. 

3. 1.2.4  Candidate  Two  Timeline  Requirements 
3 . 1 .2.4. 1  PDU  Timeline  Requirements 
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The  relative  time  line  requirements,  or  sequence  of  events,  for  the  PDU  interface  unit  is  shown  in  Figure 
3-10  and  Figure  3-11. 
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3. 1 .2.4.2  SAR  Simulator  Timeline  Requirements 


The  relative  timeline  for  the  present  SAR  processing  is  shown  in  Figure  3-10.  The  SAR  simulator  must 
operate  within  the  bounds  of  this  time  Une. 


Figure  3-10  SAR  Timeline  Candidate  Two 


3.1. 2.4.3  MTI  Simulator  Timeline  Requirements 

The  relative  timeline  diagram  for  the  MTI  simulator  for  candidate  number  two  is  shown  in  Figure  3-11. 
The  figure  shows  the  relative  timeline  requirements  for  each  process  required  to  perform  the  simulation. 
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Figure  3-11  MTI  Timeline  Candidate  Two 


3. 1.2. 5  Candidate  Two  Software  Requirements 

The  following  software  functions  must  be  developed  for  this  candidate;  DIS  network  interface,  RPS 
control.  Dead  reckoning  processing,  SAR  simulator,  MTI  simulator  and  report  processing. 

3. 1.2.5. 1  RPS  Control  Software  Requirements 

The  RPS  control  software  will  be  required  to  perform  the  simulation  initialization,  event  time  line  control, 
simulator  control,  simulation  shut  down  and  error  handling. 

3.1. 2.5.2  PDU  Software  Requirements 

The  PDU  software  will  perform  all  interface  functions  required  to  send,  receive  and  decode  entity  state 
messages  received  on  the  DIS  network.  The  PDU  software  will  also  be  required  to  perform  all 
necessary  coordinate  conversions  and  target  information  updating  (dead  reckoning).  The  PDU  software 
will  be  divided  into  two  distinct  components,  the  DIS  network  interface  and  the  Target  data  base 
process.  The  DIS  network  interface  will  be  hosted  on  a  Unix  based  workstation,  which  will  have  the 
necessary  software  to  interface  over  a  LAN  to  an  RF  data  link.  The  Target  data  base  process  will  be 
hosted  in  the  same  processor  as  the  MTI  simulator  and  will  also  interface  with  an  RF  Data  link.  The 
processing  flow  diagram  for  the  PDU  process  is  shown  in  Figure  3-6. 
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3.1.2.5.3  SAR  Simulator  Software  Requirements 

The  SAR  simulation  will  receive  terrain,  target  and  other  entity  state  information  and  perform  the 
fimctions  required  to  generate  a  proper  JOINT  STARS  SAR  image.  The  SAR  simulator  will  format 
the  image  information  into  the  proper  JOINT  STARS  format  for  transmittal  over  the  Programmable 
Signal  Processor  (PSP)  LAN  to  the  RDP.  The  software  functional  flow  for  the  SAR  processing  for 
candidate  two  is  shown  in  Figure  3-7. 


3. 1.2. 5. 4  MTI  Simulator  Software  Requirements 


The  MTI  simulator  wiU  receive  virtual  target  data  fi'om  the  RPS  control  process  and  perform  the 
necessary  functions  to  emulate  tire  JOINT  STARS  MTI  signal  processing.  The  simulation  will  be 
performed  on  a  dwell  basis.  The  software  functional  flow  for  the  MTI  processing  for  candidate  two  is 
shown  in  Figure  3-12. 
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Figure  3-12  Functional  Software  Flow  Diagram  Candidate  Two 
3.1.3  Candidate  Three  Description 

This  candidate  was  conceived  with  the  idea  of  increasing  the  fidelity  of  the  simulation  or  lowering  the 
level  at  which  the  simulation  will  be  performed.  This  candidate  will  develop  RADAR  models  and 
simulations  at  the  Coherent  Processing  Interval  (CPI)  level.  Implementation  of  this  candidate  will 
require  modeling  the  PSP  detection  process.  The  fimctionality  of  the  spare  General  Purpose  Computer 
(GPC)  be  replaced  by  the  RPS. 

3. 1.3.1  Candidate  Three  Block  Diagram 

The  functional  block  diagram  for  candidate  number  three  is  shown  in  Figure  3-13  the  added 
functionality  is  shown  as  shaded.  This  candidate  requires  that  aU  of  the  new  functionality  be  placed  in 
the  present  spare  GPC.  The  processing  required  in  candidate  number  three  will  be  performed  at  the 
coherent  processing  interval  (CPI)  level.  This  will  require  that  the  RPS  capture  the  PSP  Nodel 
message  and  inject  the  virtual  targets  every  CPI.  This  will  have  some  impact  on  the  RADAR  timeline. 
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Figure  3-13  Functional  Block  Diagram  Candidate  Three 
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3. 1.3.2  Candidate  Three  Interface  Requirements 

This  candidate  will  interface  with  the  DIS  network  through  the  PDU  interface  module  which  will  reside 
in  the  Spare  GPC.  This  will  be  done  completely  by  software  and  requires  no  additional  hardware 
interface.  The  RPS  will  interface  with  the  existing  RADAR  sensor  control  (RSC)  and  signal  processing 
(POSTPROC)  functions  via  the  PSP  and  OWS  LAN  interfaces  using  message  structures  which  have 
been  developed  for  communication  with  the  PSPs  and  CDPs. 

3 . 1 .3 .2. 1  DIS  Network  Interface  Processing 

The  candidate  processor  will  receive  the  entity  state  information  from  the  DIS  and  perform  the 
necessary  coordinate  transformations.  This  information  will  be  provided  to  the  SAR  simulator  and  the 
MTI  simulator  as  required,  via  the  Target  data  base  process. 

3. 1.3. 2. 2  RPS  Control  Interface  Requirements 

The  candidate  three  control  processing  will  perform  the  overall  function  of  controlling  the  PDU,  SAR 
simulator  and  the  MTI  simulator  and  as  such  will  be  required  to  interface  on  the  PSP  LAN  with  the 
existing  RDP  functions.  Portion  of  the  control  process  will  reside  in  the  spare  GPC  and  the  RDP.  The 
RPS  control  program  will  contain  the  capability  to  receive  and  process  the  following  messages:  PSP 
Setup  messages,  PSP  Parameter  messages,  the  MTI  report  node  1  message,  and  the  PSP  node  2 
messages. 

3.1.3.2.3  SAR  Simulator  Interface  Requirements 

The  SAR  simulator  must  receive  navigation  and  target  data  from  die  RPS  control  processor.  This  data 
will  contain  the  aircraft  platform  position  as  a  function  of  time  as  well  as  target  types  and  orientation. 
The  SAR  simulator  will  maintain  a  data  base  of  hypsographic  and  cartographic  data  required  to  develop 
the  SAR  image. 

3.1.3.2.4  MTI  Simulator  Interface  Requirements 

The  MTI  simulator  will  receive  moving  target  information  from  the  RPS  control  processor.  This 
information  will  contain  target  type,  target  position  in  TCS  coordinates  and  target  velocity.  The  MTI 
simulator  will  generate  target  locations  in  range;  cone  angle  and  associate  these  target  characteristics 
with  the  appropriate  CPIs.  These  targets  will  be  added  to  the  existing  node  1  message  which  is 
transmitted  by  the  PSP  to  the  RDP  via  the  PSP  LAN. 

3. 1.3. 3  Candidate  Three  Hardware  Requirements 

This  candidate  resides  in  the  existing  spare  GPC  and  requires  no  additional  hardware  but  will  cause  the 
spare  GPC  to  be  reconfigured  to  the  RPS. 
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3. 1.3.4  Candidate  Three  Timeline  Requirements 

3 . 1 .3 .4. 1  PDU  Timeline  Requirements 

The  relative  time  line  requirements,  or  sequence  of  events,  for  the  PDU  interface  unit  is  shown  in  Figure 
3-14  and  Figure  3-15. 

3.1.3 .4.2  SAR  Simulator  Timeline  Requirements 

The  relative  timeline  for  the  present  SAR  processing  is  shown  in  Figure  3-14.  The  SAR  simulator  must 
operate  within  the  bounds  of  this  time  line. 
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3.13 .4.3  MTI  Simulator  Timeline  Requirements 


The  relative  timeline  diagram  for  the  MTI  simulator  for  candidate  number  three  is  shown  in  Figure  3-15. 
The  figure  shows  the  relative  timeline  requirements  for  each  process  required  to  perform  the  simulation. 
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Figure  3-15  MTI  Timeline  Candidate  Three 


3. 1.3. 5  Candidate  Three  Software  Requirements 

The  following  software  functions  must  be  developed  for  this  candidate  ;  DIS  network  interface,  RPS 
control,  Dead  reckoning  processing,  SAR  simulator,  MTI  simulator  and  node  1  and  node  2  report 
processing. 

3 . 1 .3 .5 . 1  RPS  Control  Software  Requirements 

The  RPS  control  software  will  be  required  to  perform  the  simulation  initialization,  event  time  line  control, 
simulator  control,  simulation  shut  down  and  error  handling. 
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3. 1.3 .5. 2  PDU  Software  Requirements 


The  PDU  software  will  perform  all  interface  functions  required  to  send,  receive  and  decode  entity  state 
messages  received  on  the  DIS  network.  The  PDU  software  will  also  be  required  to  perform  all 
necessary  coordiaate  conversions  and  target  information  updating  (dead  reckoning).  The  PDU  software 
wiU  be  divided  into  two  distinct  components,  the  DIS  network  interface  and  the  Target  data  base 
process.  The  DIS  network  interface  will  be  hosted  on  a  Unix  based  workstation,  which  will  have  the 
necessary  software  to  interface  over  a  LAN  to  an  RF  data  link.  Target  data  base  The  process  will  be 
hosted  in  the  same  processor  as  the  MTI  simulator  and  will  also  interface  with  an  RF  Data  link.  The 
processing  flow  diagram  for  the  PDU  process  is  shown  in  Figure  3-6. 

3. 1 .3 .5.3  SAR  Simulator  Software  Requirements 

The  SAR  simulation  will  receive  terrain,  target  and  other  entity  state  information  and  perform  the 
functions  required  to  generate  a  proper  JOINT  STARS  SAR  image.  The  SAR  simulator  will  format 
the  image  information  into  the  proper  JOINT  STARS  format  for  transmittal  over  the  Programmable 
Signal  Processor  (PSP)  LAN  to  the  RDP.  The  software  functional  flow  for  the  SAR  processing  for 
candidate  three  is  shown  in  Figure  3-7. 

3.1.3.5.4  MTI  Simulator  Software  Requirements 

The  MTI  simulator  will  receive  target  entity  state  messages  from  the  RPS  control  process  and  perform 
the  necessary  functions  to  emulate  the  JOINT  STARS  MTI  signal  processing.  The  simulation  will  be 
performed  on  a  CPI  basis.  The  software  functional  flow  for  the  MTI  processing  for  candidate  three  is 
shown  in  Figure  3-16. 
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Figure  3-16  Functional  Software  Flow  Diagram  Candidate  Three 
4  Trade  Study  Process 

The  following  paragraphs  comprise  the  trade  study  evaluation  requirements  for  the  architectural  study 
for  the  RPS.  Architecture  candidates  were  identified  and  evaluated  based  on  the  criteria  described  in 
the  following  paragraphs.  The  criteria  and  their  associated  weights  are  given  in  Table  4-1  Evaluation 
Criteria.  Each  criterion  was  assigned  a  pre-weighted  value  firom  1  to  3  based  on  the  candidates  impact 
on  the  specific  criteria. 


Criterion 

Weight 

Timeline  Impact 

10 

Memory  Requirements 

2 

System  Loading 

8 

Modification  of  Existing  Software 

9 

Modification  or  Addition  of  Hardware 

6 

Use  of  Existing  Simulations  and  Models 

4 

Level  of  Simulation 

4 

Integration  Complexity 

5 

Expandability/Growth 

6 

Table  4-1  Evaluation  Criteria 
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4.1  Candidate  Evaluation  Criteria 


The  conceptual  architectural  designs  were  evaluated  on  the  criteria  delineated  in  the  following 
paragraphs.  Each  criterion  was  assigned  a  weighting  factor  to  be  used  in  the  evaluation  process. 

4.1.1  JOINT-STARS  Timeline  Impact 

Each  candidate  was  evaluated  based  on  its  impact  to  the  present  JOINT-STARS  timeline.  Those 
candidates  which  have  the  smallest  impact  on  the  timeline  were  given  the  higher  scores.  Timeline 
impacts  to  the  RADAR  subsystem  are  more  heavily  weighted  than  impacts  to  the  0\&C  subsystem. 
The  RADAR  timeline  has  more  effect  on  total  system  performance. 

4.1.2  Memory  Requirements 

Each  candidate  was  evaluated  based  on  the  amount  of  memory  required  to  implement  the  design. 
Those  candidates  with  lower  memory  requirements  received  higher  ratings. 

4.1.3  JOINT-STARS  System  Loading 

Each  candidate  was  evaluated  based  on  its  effect  on  maximum  system  loading  capabilities.  Those 
candidates  with  least  effect  were  given  higher  ratings. 

4.1.4  Modification  of  Existing  Software 

Each  candidate  was  evaluated  based  on  the  amount  of  changes  to  existing  software.  The  goal  was  to 
minimize  changes  to  the  present  JSTARS  software  in  order  to  reduce  regression  testing  liability. 
However,  minor  changes  are  acceptable  and  expected.  Candidates  requiring  the  least  amount  of 
changes  to  existing  software  achieved  the  highest  ratings. 

4.1.5  Modification  or  Addition  of  Hardware 

Each  candidate  was  evaluated  based  on  the  amount  of  modifications  required  to  existing  hardware  or 
the  addition  of  hardware.  It  was  desired  not  to  make  any  hardware  changes  therefore,  candidates 
requiring  hardware  changes/additions  received  low  ratings. 

4.1.6  Use  of  Existing  Simulations  and  Models 

Each  candidate  was  evaluated  based  on  the  number  of  simulations  and  models  to  be  developed  versus 
use  of  existing  code.  The  candidates  which  require  the  least  new  code  development  received  the 
highest  ratings. 
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4.1.7  Level  of  Simulation 


Each  candidate  was  evaluated  based  on  the  level  of  the  simulations  used.  It  was  desired  to  keep  the 
simulations  and  models  at  the  highest  level  possible  (e.g.  simulated  at  the  target  report  level).  Those 
candidates  which  require  lower  level  simulations  and  models  are  given  lower  ratings  because  in  general 
they  will  have  increased  complexity. 

4.1.8  Integration  Requirements 

Each  candidate  was  evaluated  based  on  its  integration  requirements,  that  is  to  say,  the  amount  of 
hardware,  software  and  facihties  required  for  integration  purposes.  The  candidates  which  require  the 
most  hardware,  software  and  facilities  obtained  lower  ratings. 

4.1.9  Expandability/Growth  Capabilities 

Each  candidate  was  evaluated  based  on  its  capability  of  being  expanded  at  a  later  date.  These 
candidates  will  incorporate  more  general  design  concepts  that  inherently  lead  to  their  expandability. 
These  candidates  will  receive  higher  ratings  than  those  which  restrict  or  inhibit  future  growth. 

4.2  Prototype  Software  Development 

The  trade  study  was  performed  on  the  candidates  delineated  in  the  previous  paragraphs  of  this  report. 
In  most  cases  the  information  used  to  conduct  the  trade  study  was  available  from  the  conceptual  design 
process  of  the  candidate.  However,  in  some  limited  cases  the  information  was  not  obtainable  from  the 
conceptual  design,  in  these  cases  some  level  of  prototype  software  code  development  was  necessary. 
Prototype  code  is  defined  as  code  which  performs  the  desired  functionality  but  which  has  not  been 
optimized  for  performance.  As  an  example  prototype  code  will  in  some  cases  utilize  stubs.  Stubs  are 
subroutine  calls  which  return  immediately  to  the  calling  process  wiftiout  performing  any  calculations  or 
function.  This  allows  the  testing  of  message  flow  and  handling  without  performing  the  detail  design 
function. 

43  Hardware 

In  most  cases  the  Prime  Mission  Equipment  (PME)  was  not  available  for  performing  in  depth  timing 
studies.  Therefore,  an  alternate  hardware  host  was  used  for  timing  comparisons.  A  VAX  4000  series 
90  was  used  as  the  host.  Increased  performance  may  be  expected  when  the  code  is  hosted  on  the 
targeted  PME  processors.  The  timing  data  presented  in  this  report  must  be  viewed  as  a  relative  measure 
of  performance  and  should  not  be  used  to  predict  absolute  performance.  The  hardware  set  up  for  the 
timing  data  collection  is  shown  in  Figure  4-2  and  Figure  4-3. 
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Figure  4-1  Timing  Data  Collection  Setup  Candidate  number  1 
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Figure  4-2  Timing  Data  Collection  Setup  Candidate  number  2 
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Figure  4-3  Timing  Data  Collection  Setup  Candidate  number  3 
4.4  Test  Scenario 


In  order  to  compare  timeline  impacts,  memory  utilization  and  other  trade  study  criteria  it  was  necessary 
to  develop  a  standard  test  scenario.  This  scenario  consists  of  a  virtual  target  area  (24  km  x  24  km)  and 
a  live  target  area  (4  km  x  4  km).  The  virtual  area  will  typically  be  larger  than  the  live  target  area.  The 
area  of  interest  (AOI)  is  the  search  area  (10  km  x  10  km)  as  requested  by  the  operator  and  is  where 
the  combination  of  live  and  virtual  targets  will  be  reported.  A  diagram  of  the  scenario  is  shown  in  Figure 
4-4.  The  live  area  contains  60  targets  (as  shown  in  Figure  4-5)  and  the  virtual  area  contains  5000 
targets  as  shown  in  Figure  4-6).  All  trade  study  tests  use  this  scenario  for  determining  performance. 
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Figure  4-6  Test  Scenario  Virtual  Target  Layout 

5  Trade  Study  Results 

This  section  will  present  the  results  of  the  trade  study  for  each  candidate.  The  criteria  is  shown  in  Table 
4-1  Evaluation  Criteria.  The  performance  of  each  candidate  was  evaluated  for  each  of  the  criterion 
listed  and  the  results  are  presented  in  this  section  of  the  report. 

5.1  Standard  Scenario  Baseline  Results 

5.1.1  Timeline  Impact  Candidate  One 

The  timing  results  presented  here  will  be  of  a  relative  nature  only  since  the  actual  RADAR  timeline  is  a 
very  complex  non-linear  function  of  target  loading.  The  baseline  RDP  timeline  is  shown  in  Table  5  - 1 . 


Measurement 

POINT 

Average 
Number  of 
Dwells 

Average  Time 
(msec)  Per 
Dwell 

158 

1,739 

khubbeb^^I 

158 

30 

Table  5-1  MTI  Baseline  Timing 
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5.1.2  Standard  Scenario  Baseline  Memory  Requirements 

The  memory  requirements  presented  here  will  be  of  a  relative  nature  only  since  the  actual  RADAR 
memory  utilization  is  target  dependent.  The  baseline  RDP  memory  utilization  is  3.6  megabytes. 

5.1.3  Standard  Scenario  Baseline  System  Loading 

The  CPU  utilization  for  the  standard  target  scenario  is  shown  in  Figure  5- 1 .  The  CPU  utilization  for  the 
MTI  processes, PK4MTI  and  PK4RPT  are  very  low  since  the  target  load  is  low.  The  process 
PKXAUX  which  reads  the  sensor  auxiliary  data  from  a  recorded  file  actually  takes  more  CPU  time 
than  the  MTI  processing. 
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Figure  5-1  Standard  Scenario  Baseline  CPU  Utilization 


5.2  Trade  Study  Results  Candidate  One 

The  following  paragraphs  describe  the  performance  expected  for  candidate  number  one. 

5.2.1  Timeline  Impact  Candidate  One 

The  timing  data  was  collected  with  a  set  dead  reckoning  update  rate  of  10  hz.  This  was  done  to 
investigate  the  effect  of  worst  case  dead  reckoning  on  the  overall  timeline.  The  estimated  timing  for 
candidate  number  one  is  summarized  in  Table  ~\ref{time_one_10hz}. 
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\input{sw_tiine_cl_10hz.tex} 

5.2.2  Memory  Requirements  Candidate  One 


The  estimated  additional  memory  utilized  for  candidate  number  one  over  the  baseline  3.6  megabytes  is 
summarized  in  Table  5-2. 


Process 

Name 

5,000 

DIS  TOTS 

10,000 

DIS  TOTS 

20,000 

DIS  TOTS 

MTIRPT 

1 .2  Mbyte 

2.4  Mbyte 

4.8  Mbyte 

MTISIM 

3.6  Mbyte 

7.2  Mbyte 

14.4  Mbyte 

DISNIU 

2.4  Mbyte 

4.8  Mbyte 

9.6  Mbyte 

DISNIU  (DR) 

n/a 

n/a 

n/a 

PK4MTI 

n/a 

n/a 

n/a 

PK4RPT 

n/a 

n/a 

n/a 

Table  5-2  Estimated  Memory  Utilization  Candidate  Number  One 
5.2.3  System  Loading  Candidate  One 


A  typical  CPU  utilization  plot  for  candidate  number  one  is  shown  in  Figure  5-2.  The  JADS  DIS 
process  takes  most  of  the  available  CPU  with  an  average  CPU  utihzation  of  60\%  for  this  case. 
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Figure  5-2  Standard  Scenario  Candidate  1  CPU  Utilization 
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5.2.4  Modification  of  Existing  Software  Candidate  One 

The  new  software  modules  which  will  be  required  to  be  developed  for  candidate  number  one  are  shown 
in  Tables  ~\ref{sw_new_rpt_one},  \ref{sw_new_sim_one}  and  \ref{sw_new_dis_one}. 

\input{new_code_c  l_rpt_table.tex} 

\input{new_code_c  l_sim_table.tex} 

\input{new_code_c  l_dis_table.tex} 

The  estimated  modified  lines  of  code  for  candidate  number  one  is  summarized  in  Table  5-3 . 


PK4RPT  Process 

Software  Module 

Function 

Lines  of 

Code 

SKRPO  l_MTI_REPORT 

Main  program  unit  for 
this  process. 

3 

SKRP02_INIT_REPORT 

Initializes  the  PK4RPT 
process  to  JSTARS  s/w. 

Added  mapping  to  the 
GLIV_MTI_DATA  global 
section. 

2 

SKRP05_RETRIEVE_DATA 

Receives  incoming 
messages.  Modified  to 
receive  the  RPT_TEST_ 
PARAMS_CQ  message  from 
the  MTIRPT  process. 

8 

SKRPOB_DATA_TO_OCO 

Sends  the  final  MTI 
report  onto  the  MTI 

DATA  MOT  queue. 

Modified  to  put  the 

Live  MTI  data  into  the 
GLIV_MTI_DATA  global 
section  instead  of  the 

MTI  DATA  MOT  queue, 
and  subsequently 
notify  MTIRPT  that  the 

Live  MTI  data  is  ready 

17 

PK4RPT  Totals: 

29 

Table  5-3  Estimated  Modified  Lines  of  Code  Candidate  Number  One 
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5.2.5  Modification  or  Addition  of  Hardware  Candidate  One 


Candidate  number  one  does  not  require  the  modification  or  addition  of  any  hardware  components  to  the 
JSTARS  system. 

5.2.6  Use  of  Existing  Simuiations  and  Modeis  Candidate  One 

Candidate  number  one  uses  the  screening  code  and  coordinate  conversion  code  which  was  developed 
during  the  Joint  STARS  FSD  program. 

5.2.7  Level  of  Simulation  Candidate  One 

The  RPS  candidate  number  one  is  implemented  at  the  RADAR  report  level.  This  means  tiiat  aU  the 
MTI  target  detection,  target  classification,  and  location  accuracy  processing  are  simulated  by  the  RPS. 

5.2.8  Integration  Complexity  Candidate  One 

The  integration  complexity  of  candidate  one  is  high  because  the  RPS  is  not  well  partitioned  from  the 
JOINT  STARS  prime  mission  equipment  (PME)  software.  The  ideal  integration  situation  is  to  be  able 
to  monitor  data  flow  between  processes  on  an  external  interface.  This  will  not  be  possible  with 
candidate  number  one  since  it  resides  in  the  same  processor  as  the  PME  software.  Therefore  intmsive 
software  techniques  must  be  used,  such  as  debuggers,  to  determine  faults. 

5.2.9  Expandability/Growth  Candidate  One 

The  expandability  of  RPS  candidate  number  one  is  limited  by  the  fact  that  candidate  number  one  is 
running  in  the  same  processors  as  the  PME  software  and  will  start  to  effect  the  timeline  under  the  full 
target  loading.  The  exact  point  at  which  the  five  targets  are  effected  were  not  determined  during  this 
study.  However,  some  indication  of  the  effect  can  be  seen  in  the  time  data  versus  virtual  target  load 
presented  in  Table  ~\ref{time_one_10hz}. 

53  Trade  Study  Results  Candidate  Two 

The  following  paragraphs  describe  the  performance  expected  for  candidate  number  two. 

5.3.1  Timeline  Impact  Candidate  Two 

The  timing  results  presented  here  will  be  of  a  relative  nature  only  since  the  actual  RADAR  timeline  is  a 
very  complex  non-linear  function  of  target  loading.  The  estimated  timing  for  candidate  number  two  is 
summarized  in  Table  ~\ref{time_two_10hz}. 

\input{  sw_time_c2_10hz.tex} 
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5.3.2  Memory  Requirements  Candidate  Two 


The  memory  requirements  presented  here  will  be  of  a  relative  nature  only  since  the  actual  RADAR 
memoiy  utilization  is  taiget  dependent.  The  baseline  SPARE  GPC  memory  utilization  is  zero  during 
normal  RADAR  operation.  The  estimated  SPARE  GPC  memory  utilization  for  candidate  number  two  is 
summarized  in  Table  ~\ref{memoiy_two} . 

\input{  sw_memory_c2.tex} 

5.3.3  System  Loading  Candidate  Two 

A  typical  CPU  utilization  plot  for  candidate  number  two  is  shown  in  Figure  5-3  for  the  RDP  processes 
and  Figure  5-4  for  the  Spare  GPC  processes.  The  JADS  DIS  process  takes  most  of  the  available 
CPU  with  an  average  GPC  CPU  utilization  of  75\%  for  this  case. 
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Figure  5-3  Standard  Scenario  Candidate  2  RDP  CPU  Utilization 
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F^re  5-4  Standard  Scenario  Candidate  2  Spare  GPC  CPU  Utilization 


5.3.4  Modification  of  Existing  Software  Candidate  Two 

The  new  software  modules  which  will  be  required  to  be  developed  for  candidate  number  two  are 
shown  in  Tables  ~\ref{sw_new_rpt_one},  \ref{sw_new_sim_two}  and  \ref{sw_new_dis_two}. 

\input{new_code_c2_rpt_table.tex} 

\input{new_code_c2_sim_table.tex} 

\mput{new_code_c2_dis_table.tex} 

The  estimated  modified  lines  of  code  for  candidate  number  two  is  summarized  in  Table  5-4. 
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PK4RPT  Process _ 

_ Software  Module _ _ Function _ _ Lines  of  Code 

SKRP01\_MTI\_REPORT  Main  program  unit  for  3 

this  process. 

SKRP02\_INIT\_REPORT  Initializes  the  PK4RPT  32 

process  to  JSTARS 
s/w. 

_ with  JAPS _ 

SKRP05\_RETRIEVE\_DATA  Receives  incoming  14 

messages.  Modified  to 
receive  the 

RPT\_TEST\_ 

PARAMS\_CQ 
message  from 

_ the  MTIRPT  process. _ 

SKRP08\_DATA\_TO\_OCO  Sends  the  final  MTI  33 

report  onto  the  MTI 
DATA  MOT  queue. 

Modified  to  send  the 
Live  MTI  data  to  the 

_ spare  GPC. _ 

SKRP99\_SHUTDOWN  Dumps  Timing  data  to  52 

file  whenever  PK4RPT 

_ shuts  dovm _ 

PK4RPT  Totals:  134 
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Table  5-4  Estimated  Modified  Lines  of  Code  Candidate  Number  Two 


5.3.5  Modification  or  Addition  of  Hardware  Candidate  Two 

Candidate  number  two  does  not  require  the  modification  or  addition  of  any  hardware  components  to 
the  JSTARS  system. 

5.3.6  Use  of  Existing  Simuiations  and  Models  Candidate  Two 

Candidate  number  two  uses  the  screening  code  and  coordinate  conversion  code  which  was  developed 
during  the  Joint  STARS  FSD  program. 

5.3.7  Level  of  Simulation  Candidate  Two 

The  RPS  candidate  number  two  is  implemented  at  the  RADAR  report  level.  This  means  that  all  the 
MTI  target  detection,  target  classification,  and  location  accuracy  processing  are  simulated  by  the  RPS. 

5.3.8  Integration  Complexity  Candidate  Two 

The  integration  complexity  of  candidate  two  is  low  because  the  RPS  is  well  partitioned  firom  the  JOESJT 
STARS  prime  mission  equipment  (PME)  software.  During  integration  data  flow  can  be  monitored 
between  processes  on  an  external  interface.  This  will  be  possible  using  standard  JOINT  STARS 
recording  equipment. 

53.9  Expandability/Growth  Candidate  Two 

The  expandability  of  RPS  candidate  number  two  is  limited  only  by  the  existing  memory  capability  and 
processing  speed  of  the  Spare  GPC.  This  is  tme  due  to  the  fact  that  candidate  number  two  only  effects 
the  MTI  report  delivery  time  to  the  0\&C  subsystem  which  will  not  be  detectable  by  tire  operator. 

5.4  Trade  Study  Results  Candidate  Three 

The  following  paragraphs  describe  the  performance  expected  for  candidate  number  three. 

5.4.1  Timeline  Impact  Candidate  Three 

The  timing  results  presented  here  will  be  of  a  relative  nature  only  since  the  actual  RADAR  timeline  is  a 
very  complex  non-linear  function  of  target  loading.  The  estimated  timing  for  candidate  number  three  is 
summarized  in  Table  ~\tef{time_three_10hz}. 
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\input{  sw_time_c3_  1  Ohz.tex } 


5.4.2  Memory  Requirements  Candidate  Three} 


The  memory  requirements  presented  here  will  be  of  a  relative  nature  only  since  the  actual  RADAR 
memory  utilization  is  target  dependent.  The  baseline  SPARE  GPC  memory  utilization  is  zero  during 
normal  RADAR  operation.  The  estimated  SPARE  GPC  memory  utilization  for  candidate  number  three 
is  summarized  in  Table  ~\ref{memory_three}. 

\input{sw_memory_c3.tex} 

5.4.3  System  Loading  Candidate  Three 

A  typical  CPU  utilization  plot  for  candidate  number  three  is  shown  in  Figure  5-5  for  the  RDP  processes 
and  Figure  5-6  for  the  Spare  GPC  processes.  The  JADS  DIS  process  takes  most  of  the  available 
CPU  with  an  average  GPC  CPU  utilization  of  75\%  for  this  case. 
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Figure  5-5  Standard  Scenario  Candidate  3  RDP  CPU  Utilization 
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Figure  5-6  Standard  Scenario  Candidate  3  Spare  GPC  CPU  Utilization 
5.4.4  Modification  of  Existing  Software  Candidate  Three 

The  new  software  modules  which  will  be  required  to  be  developed  for  candidate  number  three  are 
shown  in  Tables  ~\ref{sw_new_JDSNDl_three},  \ref{sw_new_sim_three}  and 
\ref{sw_new_dis_three}.  The  estimated  modified  lines  of  code  for  candidate  number  three  is 
summarized  in  Table  ~\ref{sw_mod_three_ncp}. 

\input{new_code_c3_JDSND  l_table.tex} 

\input{new_code_c3_sim_table.tex 
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1  JADS  DISNIU  PROCESS 

Software  Module 

Function 

Lines  of  Code 

DISNIU_Fill 

Simulates  Reception  of 

DIS  PDUs 

60 

DISNIU_FILTER_PDUs 

Filters  Entity  State 

PDUs 

36 

DISNIU_Mam 

Init  socket  interface 
receive  msg  from  DIS  LAN 
maps  to  MTISIM  common  DB 
performs  dead  reckoning 

180 

DISNIU_REPORT 

Dumps  PDU  DataBase  Time 
numbers  to  file 

21 

DISNIU_DR_Report 

Dumps  dead  reckoning 
timing  numbers  to  file 

20 

Init_Topo 

init  topo  origin 

10 

Geoc_To_Topoc 

convert  from  Geo  to 

Topo  coordinates 

10 

Topoc_To_Geoc 

convert  from  Topo  to 

Geo  coordinates 

10 

Geod_To_Geoc 

convert  from  Geod  to 

Geo  coordinates 

8 

Byte_Swap_Lword 

byte  swap  4  byte  word 

10 

By  te_S  wap„W  ord 

byte  swap  2  byte  word 

8 

Lword_S  wap_T  o_D  word 

byte  swap  8  byte  word 

7 

VAX2IEEE_Init 

VAX  to  IEEE  initialize 

3 

VAX2IEEE_Short 

VAX  to  IEEE  single  prec 

3 

VAX2IEEE_Float 

VAX  to  IEEE  Float  point 

4 

VAX2IEEE_Double 

VAX  to  IEEE  double  prec 

5 

CVT_DIEEE_TO_DVF 

converts  little  endian/ 

IEEE  value  to  VAX  value 

12 

CVT_DVF_TO_DIEEE 

converts  VAX  value  to 
little  endian/IEEE  value 

11 

CVT_lEEE_TO_VF 

converts  little  endian/ 

IEEE  value  to  VAX  value 

10 

CVT_VF_TO_IEEE 

converts  VAX  value  to 
little  endian/IEEE  value 

10 

DISNIU  Totals: 

438 

Table  5-5Estimated  New  Lines  of  Code  Candidate  Number  Three  cont'd 

PTNOWA  Process 

Software  Module 

Function 

Lines  of  Code 

Main 

Main  program  unit  for 
this  process. 

222 
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I  PTNOWA  Totals;  222 

Table  5-6  Estimated  Modified  Lines  of  Code  Candidate  Number  Three 


5.4.5  Modification  or  Addition  of  Hardware  Candidate  Three 

Candidate  number  three  does  not  require  the  modification  or  addition  of  any  hardware  components  to 
the  JSTARS  system. 

5.4.6  Use  of  Existing  Simulations  and  Models  Candidate  Three 

The  level  at  which  candidate  number  three  injects  the  virtual  targets  requires  that  aU  new  models  and 
simulations  be  developed. 

5.4.7  Level  of  Simulation  Candidate  Three 

The  RPS  candidate  number  three  is  implemented  at  the  RADAR  CPI  level.  This  means  that  aU  the 
target  classification,  and  location  accuracy  processing  are  simulated  by  the  RPS. 

5.4.8  Integration  Complexity  Candidate  Three 

The  integration  complexity  of  candidate  three  is  lower  than  candidate  number  one  because  the  RPS  is 
well  partitioned  fi'om  the  JOINT  STARS  prime  mission  equipment  (PME)  software.  During  integration 
we  will  be  able  to  monitor  data  flow  between  processes  on  an  external  interface.  This  will  be  possible 
using  our  standard  JOINT  STARS  recording  equipment.  However,  the  complexity  is  greater  than 
candidate  number  two  because  of  the  content  and  volume  of  the  message  data 
transferred  between  processors. 

5.4.9  Expandability/Growth  Candidate  Three 

The  expandability  of  RPS  candidate  number  three  is  limited  by  the  existing  memory  capability  and 
processing  speed  of  the  Spare  GPC.  The  candidate  number  three  software  must  handle  every  Node  1 
message  and  therefore  by  it's  very  nature  impact  tire  RADAR  timeline.  This  timeline  effect  will  be 
noticeable  under  full  target  load. 


A -53 


6  Trade  Study  Conclusions 


The  following  paragraphs  comprise  the  results  of  the  architectural  trade  study  for  the  JADS  RPS.  An 
overall  summaiy  of  the  trade  study  results  are  given  in  Table  6-1 . 


Candidate 

Criterion 

Weight 

Number  1 

Number  2 

Number  3 

Timeline  Impact 

10 

2 

3 

1 

Memory  Requirements 

2 

1 

3 

2 

System  Loading 

8 

1 

3 

2 

Modification  of  Existing  Software 

9 

1 

2 

3 

Modification  or  Addition  of  Hardware 

6 

3 

3 

3 

Use  of  Existing  Simulations  and  Models 

4 

3 

3 

3 

Level  of  Simulation 

4 

2 

2 

3 

Integration  Complexity 

5 

1 

2 

2 

Expandibility/Growth 

6 

1 

3 

3 

Total 

88 

144 

127 

Table  6-1  Evaluation  Results  Summary 

Candidate  number  two  is  the  clear  choice  for  the  JADS  implementation  in  the  JOINT  STARS  system. 

It  is  low  risk  with  acceptable  performance.  The  following  general  conclusions  can  be  drawn  fix)m  the 

architectural  study. 

•  Candidate  number  one  has  the  most  undesirable  effect  of  being  able  to  limit  the  radar's  performance 
due  to  timeline,  memory  and  CPU  utilization. 

•  Candidate  number  two  has  the  least  impact  on  radar  performance.  The  delay  that  is  incurred  in  this 
candidate  is  only  a  delay  in  deUveiy  of  the  reports  to  the  operator  and  as  such  does  not  impact 
radar  timeline  or  performance. 

•  Candidate  number  three  has  more  of  an  advantage  from  a  testing  stand  point  in  that  it  can  be  used 
to  throughly  test  the  Radar  Data  Processor  processes.  It  can  however,  under  full  target  load  have  a 
severe  effect  on  the  radar  timeline. 
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1.  Scope 


This  docviment  establishes  the  hardware  and  software  requirements  to  meet  the  system  design  goals  for 
the  Radar  Processor  Simulation  (RPS)  being  developed  for  the  purposes  of  integrating  Joint-STARS 
into  a  Joint  Advanced  Distributed  Simulation  (JADS)  environment.  The  requirements  specified  in  this 
document  are  for  those  techniques  specific  to  the  development  of  the  RPS  in  the  JADS  environment. 
Algorithms  and  techniques  developed  for  Joint  STARS  are  referenced  in  this  document,  but  are  not 
specified  in  detail.  A  typical  JADS  environment  is  shown  I  Figure  l.-l. 


Figure  l.-l.  Typical  JADS  Environment 

The  general  concept  of  operation  for  Joint  STARS  within  such  an  environment  is  as  follows: 


•  The  Joint  STARS  aircraft  will  fly  over  a  government  controlled  facility  (such  as  Ft.  Irwin) 

•  A  small  area  will  contain  controlled  targets,  tanks,  tmcks,  etc. 
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•  A  target  /  war  simulation  such  as  JANUS  wOl  be  operating  at  a  government  facility  such  as 
White  Sands  Missile  Range  (WSMR)  generating  Aortual  targets  and  issuing  Protocol  Data 
Units  (PDUs)  on  the  Distributed  Interactive  Simulation  (DIS)  network 

•  The  RPS  will  receive  the  virtual  target  information,  from  the  DIS  network  via  entity  state 
PDUs  and  supply  virtual  target  radar  reports  combined  with  the  live  target  radar  reports 

Figure  1.-2  is  a  block  diagram  for  Joint  STARS  identilying  the  functional  layout  of  its  five  subsystems; 
(1)  Operations  and  Control;  (2)  Data  Link;  (3)  Communications;  (4)  Radar;  and  (5)  Aircraft 
Subsystems. 


Figure  1.-2.  Joint  STARS  System  Block  Diagram 

The  Architectural  Design  Report  (JADS-RPT-001)  referenced  in  section  2  proprosed  three  candidate 
architectures  to  implement  the  RPS  within  Joint  STARS.  One  of  the  primary  design  goals  presented  in 
the  Architecture  Design  Report  is  minimizing  modification  to  existing  Joint  STARS  software.  With  this 
goal  in  mind,  all  three  candidates  were  designed  using  similar  algorithms  and  techniques  which  required 
little  or  no  software  modifications.  Since  the  algorithms  used  by  the  candidates  are  very  similar,  the 
software  requirements  which  drive  the  algorithms  tend  to  transcend  a  specific  architecture,  so  that  this 
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design  report  may  assume  that  any  of  the  candidate  architectures  will  be  selected  for  implementation  of 
theRPS. 

2.  Applicable  Documents 

The  following  is  a  list  of  the  applicable  documents. 


Document  Name 

Date  of  Issue 

Revision 

Engineering  Services  Task  (EST)  Statement  of 
Work  E-8C  RADAR  Processor  Simulation 

System  Specification  For  Joint  Surveillance 

Target  Attack  RADAR  System 

AN/USY-TBD  (JOINT  STARS) 

21  December  1992 

Prime  Item  Development 

Specification  For  RADAR 

Subsystem  AN/APY-(TBD)  For 

Joint  Surveillance  Target 

Attack  RADAR  System  (JOINT  STARS) 

12  June  1991 

Architecture  Design  Report  for  the 

RADAR  Processor  Simulation  for  the 

Joint  Surveillance  Target 

Attack  RADAR  System  (JOINT  STARS) 

March  1996 

Standard  for  Distributive  Interactive 

Simulation  -  Application  Protocols 

Version  2.0.4 

16  March  1994 

Security  Classification  Guide 

Joint  STARS 

Version  2.0.4 

9  March  1994 

Interface  Control  Docxmient  for  the 

SAR  Imagery  Simulation  of  the  Joint  STARS 
Radar  Processor  Simulation 

TBD 
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3.  Requirements 

The  hardware  and  software  requirements  specific  to  the  development  of  the  RPS  within  Joint  STARS 
will  be  presented  in  this  section. 

3.1  Hardware  Requirements 

This  section  presents  the  hardware  requirements  for  the  incorporation  of  the  RPS  into  the  Joint  STARS 
system.  Since  one  of  the  primary  system  design  goals  for  the  RPS  is  to  limit,  if  not  eliminate,  hardware 
modifications  to  the  Joint  STARS  system,  there  are  few  hardware  requirements  placed  on 
irnplementation  of  the  RPS.  Under  normal  conditions,  the  RPS  shall  [1]  consist  of  two  distinct 
architectures,  one  on  the  ground  (3.1.3)  interfacing  with  the  DIS  network,  and  one  on-board  the  Joint 
STARS  platform  (3.1.4)  performing  the  MTI  and  SAR  Imagery  simulations.  These  two  architectures 
shall  [2]  be  connected  by  an  RF  Link  (3.1.2)  during  flight  mode  and  with  a  LAN  while  in  the  lab 
environment. 

3.1.1  Joint  STARS  Configuration 

The  RPS  shall  [3]  be  developed  for  incorporation  into  the  third  aircraft  configuration  used  for  low  rate 
initial  production  of  the  E-8C  Joint  STARS. 

3.1.2  RFLink 

The  bandwidth  requirements  for  the  RF  Link  will  be  developed  during  the  detailed  design  phase  of  the 
RPS  from  message  load  tests  with  the  assistance  of  the  JADS  JTF. 

3.1.3  Down  Link  Architecture 

The  down  link  processes  developed  for  the  RPS  will  be  hosted  in  a  general  purpose  computer  capable 
of  processing  the  maximum  PDU  rates  and  capacities  specified  in  3.2.L3.  The  down  link  architecture 
shall  [4]  be  capable  of  logging  PDUs  for  future  data  analysis  and  test  purposes. 

3.1.4  Up  Link  Architecture 

The  up  link  processes  developed  for  the  RPS  shall  [5]  be  hosted  in  one  or  more  of  the  Joint  STARS 
general  purpose  computers  (GPC)  on  board  the  platform.  The  JADS  Architectural  Design  Report 
identifies  the  RDP  GPC,  SPR  GPC,  and  the  ATWS  as  possible  candidates  for  hosting  the  up  link  RPS 
architecture. 
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3.2  Software  Requirements 


This  section  presents  the  software  requirements  for  four  functional  levels  of  the  system  design;  (1)  RPS 
control;  (2)  MTI  Simulation;  (3)  SAR  Imagery  Simulation;  (4)  and  Stand  Alone  operations. 

3.2.1  RPS  Control 

The  RPS  control  function  will  provide  the  interface  between  the  Joint  STARS  functions,  the  RPS 
functions  and  the  external  JADS  environment.  Within  the  RPS,  the  control  function  will  provide  the 
MTI  (3.2.2)  and  SAR  hnageiy  (3.2.3)  simulation  with  the  appropriate  Joint  STARS  data  and  external 
JADS  data  to  perform  their  functionality. 

3. 2. 1.1  Initialization 

The  RPS  win  be  initialized  with  the  data  described  in  this  section. 

3 .2. 1 . 1 . 1  Identify  Live  AOIs 

A  live  area  of  interest  (LAOI)  is  defined  as  a  rectangular  region  of  interest  entirely  located  within  the 
512-by-512  Km  primary  region  of  interest.  Within  these  LAOIs,  only  “live”  targets  detected  by  Joint 
STARS  shall  [6]  be  reported.  Outside  of  these  LAOIs,  only  “virtual”  targets  supplied  to  the  RPS  shall 
[7]  be  reported.  The  RPS  shall  [8]  maintain  up  to  four  LAOIs.  The  set  of  LAOIs  shall  [9]  be  provided 
by  the  customer  as  a  file  to  be  read  in  upon  initialization  of  the  RPS  and  cannot  be  modified  during  the 
JADS  exercise. 

3.2. 1 . 1.2  Identify  Hypso  and  Carto  Database 

The  hypsographic  and  cartographic  databases  defining  the  features  of  the  Joint  STARS  primary  region 
shall  [10]  be  replaced  upon  initialization  of  tihe  RPS  with  a  new  set  of  databases  incorporating  the  virtual 
features  for  the  JADS  mission.  These  databases  will  be  the  same  format  as  those  used  for  the  Joint 
STARS  mission  and  will  be  supplied  by  the  customer.  For  SAR  Imagery,  a  SAR  features  database  will 
be  developed  and  supplied  by  the  customer. 

3.2. 1.2  Operator  Controls 

The  RPS  operator  shall  [1 1]  be  given  modest  control  of  simulation  parameters  through  the  use  of  flags 
and  thresholds.  The  set  of  modifiable  parameters  will  be  at  least,  but  not  limited  to  the  following; 

•  Enable  /  Disable  MTI  Pd 

-  If  enabled,  minimum  and  maximum  Pd.  (Pd  =  1  if  disabled) 
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Enable/ Disable  MTI  CEP 


-  If  enabled,  maximum  down  range  and  cross  range  error.  (CEP  =  0  if  disabled) 

•  Enable  /  Disable  MTI  Terrain  Screening 

•  Enable  /  Disable  MTI  False  Alarms 

•  Weather  conditions  as  Clear,  Cloud,  or  Rain 

•  Joint  STARS  Entity  State  (ES)  Protocol  Data  Unit  (PDU)  Heartbeat  Period 

•  Joint  STARS  ES  PDU  Platform  Position  Update  Threshold 
3. 2. 1.3  DIS  Interface  Control 

The  RPS  control  function  shall  [12]  receive  ES  PDUs  over  the  DIS  network  and  maintain  a  database  of 
those  ES  PDUs  applicable  to  the  Joint  STARS  mission. 

3.2.1.3.1  DIS  Network 

ES  PDUs  shall  [13]  be  managed  in  two  separate  architectures,  one  on  the  ground  connected  to  the  DIS 
network,  referred  to  as  DISNIU  I,  and  a  second  on  the  platform  connected  to  the  Joint  STARS  OWS 
and  /  or  PSP  LAN,  referred  to  as  DISNIU  II.  When  operating  in  flight  mode,  they  will  be  connected 
by  an  RF  link.  When  operating  in  a  lab  environment,  they  will  be  connected  with  a  LAN.  DISNIU  I 
shall  [14]  use  the  TCP/IP  UDP  protocol  for  communication  on  the  DIS  network. 

3.2. 1.3 .2  Receive  Entity  State  PDUs 

The  Entity  State  (ES)  Protocol  Data  Unit  (PDU)  is  the  primary  type  required  to  be  acted  upon  by  the 
RPS.  ES  PDUs  contain  information  about  a  particular  entity  as  described  in  the  DIS  standard  (2.).  An 
entity  can  be  any  object  such  as  a  tank,  a  buck,  an  aircraft,  a  bridge,  a  building,  etc...,  and  is 
considered  a  virtual  target  by  the  RPS.  The  RPS  will  receive  new  ES  PDUs  by  the  war-games 
simulation,  followed  by  a  periodic  “heartbeaf  ’  ES  PDU  for  each  entity  to  affirm  reception  by  the  RPS. 
Virtual  target  updates  will  be  received  by  the  RPS  via  ES  PDUs  when  the  position  of  the  virtual  target 
has  exceeded  the  pre-determined  threshold  based  on  dead  reckoning  (3.2. 1.3.5)  updates  by  the  war- 
games  simulation.  The  RPS  shall  [15]  be  required  to  maintain  at  least  5000  virtual  targets,  with  a 
growth  capacity  of  at  least  20000  virtual  targets.  Virtual  targets  shall  [16]  be  deleted  by  the  RPS  when 
the  war-games  simulation  issues  a  Remove  Entity  PDU  or  if  “deactivated”  by  an  ES  PDU. 
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3 .2. 1 .3 .3  Coordinate  Conversion 


ES  PDUs  received  over  the  DIS  network  contain  position  and  velocity  information  in  the  Earth- 
Centered-Earth-Fixed  (ECEF)  coordinate  system  using  the  1984  World  Geographic  System  earth 
model  (WGS-84).  ES  PDU  position  and  velocity  shall  [17]  be  converted  from  ECEF  to  the  Joint 
STARS  Topocentric  Coordinate  System  (TCS)  by  SIDNIU  I  in  order  to  save  processor  load  for  the 
real-time  MTI  (3.2.2)  and  SAR  hnageiy  (3.2.3)  simulations  on  the  platform.  ES  PDU  orientation  shall 
[18]  be  converted  from  the  entity  coordinate  system  to  TCS  by  DISNIU  I. 

3.2.1.3.4  Filter  Entity  State  PDUs 

ES  PDU  information  applicable  to  the  MTI  and  SAR  Imagery  simulations  shall  [19]  be  reduced  to  the 
minimum  amount  of  information  required  by  the  real-time  simulations  in  order  to  minimize  the  use  of  the 
available  RF  Link  bandwidfli.  As  a  minimum,  the  ES  PDUs  will  be  reduced  to  a  virtual  entity  described 
by  its  unique  identifier,  entity  type,  time  tag,  position,  velocity,  orientation,  and  appearance.  Currently, 
ES  PDUs  will  be  received  from  a  single  source,  so  that  identification  of  each  ES  PDU  may  be 
accomplished  using  a  umque  entity  ED  (STTE  =  APPLICATION).  The  software  design  should 
accommodate  multiple  sites  and  applications  as  a  growth  provision. 

ES  PDU  filtering  shall  [20]  be  performed  on  a  maximxim  sustained  rate  of  100  virtual  target  updates  per 
second  plus  the  heartbeat  rate.  After  DISNIU  I  has  coordinate  converted  and  reduced  the  ES  PDU  to 
its  minimuna  length,  the  virtual  target  updates  will  be  sent  up  the  RF  Link  to  the  DISNIU  IL  If  the 
currently  undefined  RF  Link  bandwidth  cannot  support  the  virtual  target  update  rate,  then  further  data 
compression  may  be  required  along  with  a  geometrical  filter  placed  around  existing  RSR  AOIs  to 
reducr  the  number  of  virtual  target  updates  sent  over  the  RF  Link.  If  a  geometrical  filter  is  necessary, 
the  virtual  target  dead  reckoning  (3.2.L3.5)  will  also  be  required  in  DISNIU  1. 

3.2.L3.5  Dead  Reckoning 

Virtual  targets  received  by  DISNIU  II  shall  [21]  be  extrapolated  to  current  time  at  a  minimum  rate  of  5 
Hz  using  a  first  order  position  update  (P  =  Pq  +  VAT).  Timing  studies  in  the  Architectural  Design 
Report  indicate  that  first  order  target  dead  reckoning  does  not  adversely  effect  the  radar  timeline  even 
when  the  number  of  targets  exceeds  the  current  virtual  target  capacity.  Dead  reckoned  virtual  targets 
will  be  make  available  to  the  MTI  (3.2.2)  and  SAR  hnageiy  (3.2.3)  simulations. 

3.2. 1.3.6  Joint  STARS  Entity  State  PDU 

DISNIU  n  will  send  state  information  about  the  Joint  STARS  Platform,  including  position  and  velocity, 
down  the  RF  Link  to  DISNIU  I,  which  will  be  converted  to  an  ES  PDU  and  output  over  the  DIS 
network.  The  Joint  STARS  state  message  shall  [22]  be  sent  at  a  1  Hz  rate  by  DISNIU  H  and  output 
over  the  DIS  network  by  DISNIU  I  when  the  dead  reckoned  platform  position  varies  by  more  than  the 
operator  specified  Joint  STARS  position  threshold,  or  its  heartbeat  timer  has  expired. 
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3. 2. 1.4  Live  Target  Control 

The  RPS  win  provide  the  MTI  Simulation  (3.2.2)  those  targets  detected  by  the  Joint  STARS  radar  for 
the  current  radar  beam  dwell.  Depending  upon  the  architecture  selected,  these  “live”  targets  may  be 
provided  as  threshold  crossings  on  a  coherent  processing  interval  (CPI)  basis,  or  as  associated  targets 
on  a  beam  dwell  basis. 

3.2.2  MTI  Simulation 

The  MTI  simulation  will  receive  as  input  from  the  RPS  control  function  (3.2.1)  the  current  beam  dwelTs 
live  targets  and  the  moving  virtual  targets  received  form  the  DIS  interface.  The  virtual  targets  shall  [23] 
be  geometrically  filtered,  have  MTI  statistics  applied,  and  mixed  with  the  appropriate  five  targets  for 
output  from  the  radar  subsystem.  The  processing  required  by  the  MTI  simxilation  shall  [24]  not  degrade 
the  radar  timeline  beyond  the  nominal  timeline  fluctuations  experienced  by  the  Joint  STARS  radar  under 
heavy  target  load  conditions. 

3.2.2.1  MTI  Control 

The  MTI  control  function  shall  [25]  determine  those  virtual  targets  within  the  current  beam  dwell 
footprint  but  not  within  the  LAOIs. 

3 .2.2. 1 . 1  Reverse  Area  Blanking 

For  each  radar  coherent  processing  interval  (CPI),  those  range  bins  which  interact  one  or  more  of  the 
LAOIs  will  be  identified  for  consideration  of  five  targets.  Range  bins  which  do  not  intersect  an  LAOI 
will  be  identified  for  consideration  of  virtual  targets. 

3 .2.2. 1 .2  Beam  Dwell  Footprint 

For  each  radar  beam  dwell,  a  beam  fooq)rint  will  be  determined  from  the  initial  cone  angle,  range 
coverage,  and  beamwidth  parameters  provided  in  the  radar  AUX  data.  The  radar  AUX  data  is 
available  within  several  messages  throughout  the  radar  subsystem.  The  beam  foo^iint  will  be 
approximated  as  a  quadrilateral  in  the  Topocentric  Coordinate  System  (TCS)  for  easy  comparison  with 
live  and  virtual  targets  already  defined  in  TCS.  For  each  Radar  Service  Request  (RSR)  actively  being 
scanned,  the  beam  dwell  footprints  will  be  contiguously  maintained  without  overlap  until  a  start  of  revisit, 
start  of  swath,  or  a  resumption  of  revisit  condition  occurs,  for  which  a  complete  foo^rint  must  be 
computed. 

3 .2.2. 1 .3  Filter  Live  Targets 
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Targets  detected  by  the  Joint  STARS  radar  will  be  considered  “live”  targets.  Only  those  live  targets 
which  reside  inside  a  LAOI  shall  [26]  be  considered  “detected”  by  the  RPS.  All  live  targets  which 
reside  outside  the  LAOIs  (aka  virtual  area)  will  not  be  considered  a  detected  target  by  the  RPS.  Live 
targets  being  filtered  on  a  CPI  basis  will  only  be  considered  if  they  fall  within  the  LAOI  range  bins 
determined  in  reverse  area  blanking  (3.2.2.1.1). 

3.2.2.1.4  Filter  Virtual  Targets 

Moving  targets  within  the  entity  database  will  be  considered  “virtual”  targets.  Only  those  virtual  targets 
which  reside  outside  the  LAOIs  (aka  virtual  area)  and  within  the  current  radar  beam  dwell  footprint  shall 
[27]  be  considered  for  possible  “detection”  by  the  RPS.  The  MTI  processing  (3.2.2.2)  fimction  will 
determine  which  virtual  targets  will  actually  by  detected.  Timing  studies  in  tiie  Architectural  Design 
Report  indicate  that  virtual  target  filtering  for  conditions  exceeding  the  current  virtual  target  capacity 
adversely  effects  the  radar  timeline.  For  these  conditions,  a  grid  filtering  technique  shows  some  promise 
for  reducing  the  radar  timeline  to  a  manageable  level.  The  grid  filtering  technique  requires  the  virtual 
targets  to  be  pre-sorted  into  a  series  of  X-Y  grids  which  can  be  quickly  checked  against  the  radar  beam 
fooq)rint,  thereby  quickly  eliminating  a  significant  number  of  virtual  targets  from  consideration.  The  goal 
of  this  tradeoff  wouldbe  to  define  the  grid  size  to  minimize  the  number  of  grids  plus  targets  to  check 
against  the  radar  beam  footprint  and  minimize  the  management  overhead  of  the  grid  structure. 

3. 2.2. 1.5  Mix  Live  and  Virtual  Targets 

For  each  radar  beam  dwell,  the  detected  live  moving  targets  (3.2.2.1.3)  and  the  detected  virtual  moving 
targets  (3 .2.2.2)  shall  [28]  be  merged  into  a  single  dwell  report  representing  a  mix  of  live  and  virtual 
targets  within  the  same  beam,  but  not  overlapping  in  physical  space.  Depending  upon  the  selected 
architecture,  this  functionality  may  be  achieved  prior  to,  or  after,  target  association  occurs  within  the 
RDO  post  processing  function. 

3. 2. 2. 2  MTI  Processing 

After  the  MTI  control  function  (3.2.2. 1)  filters  the  virtual  targets  based  on  beam  dwell  and  LAOI 
geometry,  this  simulation  shall  [29]  aeate  a  subset  of  these  virtual  targets  which  exhibit  similar 
characteristics  as  live  Joint  STARS  targets  would  under  the  same  scan  conditions.  These  virtual  targets 
will  have  moving  target  indicator  statistics  applied  and  will  be  output  to  the  MTI  control  function  to  be 
mixed  with  the  appropriate  live  targets  detected  in  tire  same  beam. 

3.2.2.2.1  Beam  Dwell 

The  radar  beam’s  range  coverage,  azimuth,  and  3dB  dwell  time  will  be  derived  for  each  beam  dwell 
from  the  radar  AUX  data.  The  radar  beam’s  range  coverage  extends  the  specified  number  of  range 
bins  from  the  range  start  value  adjusted  by  the  radar  zero  range  delay  and  range  refiaction  correction. 
The  radar  beam  azimuth  coverage  is  defined  by  the  cosine  cone  angle  term  and  the  specified  beam 
spacing.  The  radar  dwell  time  is  derived  from  the  radar  pulse  repetition  interval  (PRI),  the  number  of 
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integrated  pulses,  and  the  waveform  identifier.  Since  the  Joint  STARS  radar  uses  variable  beam 
spacing,  the  dwell  time  will  be  normalized  to  the  3dB  spacing  using  the  azimuth  angle  and  the  actual 
beam  spacing  commanded.  The  waveform  identifier  indicates  the  PRFs  used  in  the  beam  dwell. 


3.22.2.2  Environmental  Conditions 

Applicable  external  environmental  conditions  will  be  considered  to  effectively  model  moving  targets. 
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3.2.2.2.2.1  Weather 


Weather  conditions  shall  [30]  be  assumed  to  be  one  of  three  categories;  (1)  clear;  (2)  cloud;  (3)  rain;  as 
defined  in  the  Joint  STARS  System  Specification,  as  selected  by  the  JADS  operator  (3 .2. 1.2).  Future 
considerations  should  be  made  for  incorporation  of  weather  PDUs  defining  regions  of  weather 
coverage.  From  the  selected  weather  condition,  an  additional  signal-to-noise  (S/N)  variation  over  the 
range  coverage  will  be  computed  for  use  by  the  Pd  (3.2.2.2.3.5)  and  location  accuracy  (3.2.2.2.3.3) 
functions.  The  additional  S/N  loss  will  be  determined  based  on  the  Joint  STARS  System  Specification 
losses  for  each  weather  condition. 

3.2.2.2.2.2  Refraction 

A  range  refraction  curve  will  be  derived  for  the  range  coverage  of  each  beam  dwell  and  applied  to  the 
down  range  target  statistics  for  location  accuracy  (3.2.2.2.3.3).  The  method  employed  by  Joint 
STARS  to  determine  the  range  refraction  correction  shall  [31]  be  used  by  the  RPS  to  enhance 
symmetry  between  live  and  virtual  targets. 

3.2.2.2.23  Terrain 

The  RPS  shall  [32]  identify  those  virtual  targets  obscured  by  terrain  based  on  the  hypsographic 
database,  and  the  current  platform  position  along  the  radar  beam’s  line  of  sight.  As  indicated  in  figure 
3.2-1,  when  the  elevation  of  the  target  to  the  platform  is  less  than  the  elevation  of  the  target  to  the 
highest  grid  point  along  the  beam’s  line  of  sight,  then  that  target  is  considered  screened  by  the  terrain 
and  not  eligible  for  detection. 
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3.2.2.2.3  Virtual  Target  Statistics 

MTI  statistics  shall  [33]  be  applied  stochastically  to  the  virtual  targets  using  a  uniformly  distributed 
random  number  sequence  in  order  to  effectively  simulate  virtual  targets  as  Joint  STARS  targets.  All 
virtual  target  statistics  will  be  derived  from  a  single  random  number  seed. 

3.2.2.2.3.1  Virtual  Target  Geometry 

The  MTI  Control  function  (3 .2.2.1)  will  provide  those  virtual  targets  to  be  considered  for  MTI 
processing.  These  targets  have  been  dead  reckoned  to  the  current  beam  dwell  time  and  as  a  minimum 
are  represented  by  its  target  position  (Pt)  and  velocity  (Vt)  vectors  in  TCS.  Pt  and  Vt  represent  the 
ground  tmth  of  the  target  for  which  MTI  statistics  wiU  be  applied.  Each  target’s  ground  truth  will  be 
converted  to  radar  coordinates  of  range,  azimuth,  and  radial  velocity. 

3.2.2.2.3.2  Radar  Cross  Section 

The  RPS  win  use  a  nominal  sized  target  defined  in  the  Joint  STARS  System  Specification.  Virtual  target 
amplitudes  will  vary  as  a  function  of  range  with  random  fluctuations  within  a  5dB  tolerance  interval. 

3.2.2.2.3.3  Location  Accuracy 

Target  location  accuracy  is  measured  using  the  Circular  Error  Probable  (CEP)  method  with  separate 
down  and  cross  range  errors  assumed  to  be  uncoirelated  forming  a  linear  error  model  shown  in  figure 
3.2-2.  S/N  variations  due  to  weather  and  range  will  be  modeled  for  determination  of  the  one  sigma 
cross  range  component  in  the  linear  model.  AmpUtude  and  frequency  modulation  techniques  will  be 
applied  to  the  mean  and  one  sigma  error  statistics  to  prevent  integrated  targets  from  looking  too 
“simulation-like”.  These  modulation  techniques  have  the  effect  of  moving  a  smaller  CEP  circle  within  a 
larger  CEP  circle  to  aehieve  the  same  CEP  results  with  fewer  unreahstic  random  fluctuations.  Once  the 
down  range  and  cross  range  error  has  been  established,  these  values  shall  [34]  be  applied  to  the 
position  vector  (Pt)  of  the  target.  The  down  range  error  is  applied  in  the  TCS  X-Y  plane  along  die 
beam’s  line  of  sight  to  the  target,  while  the  cross  range  error  is  applied  perpendicular  to  the  beam’s  line 
of  sight  to  the  target. 
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SIGMflX/SIGMRY 

Figure  3.2-2.  Circular  Error  Probable  (CEP) 

3.2.2.2.3.4  Target  Resolution 

Multiple  targets  located  within  the  same  range  /  doppler  cell  cannot  be  distinguished  from  each  other,  so 
that  Joint  STARS  range,  velocity  and  angle  resolution  constraints  will  be  applied  to  target  detection 
statistics.  If  multiple  targets  caimot  be  distinguished,  then  only  one  target  may  be  detected. 

3.2.2.2.3.5  Probability  of  Detection  (Pd) 

The  average  Pd  of  a  target  (Pdt)  is  fundamentally  related  to  target  S/N  as  derived  from  the  radar  range 
equation.  The  Joint  STARS  radar  is  designed  to  compensate  for  two  major  S/N  factors  in  real  time  by 
varying  the  radar  beam  dwell  time  as  a  function  of  azimuth  and  range.  These  S/N  factors  are  azimuth 
beam  broadening  losses  resulting  from  steering  the  beam  electronically  in  azimuth,  and  target  range  loss. 
Radar  operating  curves  (3.2.2.2.4)  shall  [35]  be  developed  off  line  which  relate  the  radar  beam  dwell 
time  to  the  Joint  STARS  azimuth  (figure  3.2-3)  and  range  (figure  3.24)  constraints  for  a  family  of  Pd 
and  S/N  levels.  Analysis  has  shown  that  these  curves  are  reasonably  well  behaved  and  can  be  modeled 
using  a  Lagrange  interpolation  series  of  four  points. 

The  Lagrange  interpolation  coefficients  can  be  expanded  in  azimuth  and  range  to  derive  the  theoretical 
3dB  dwell  times  for  various  average  Pd  levels,  from  which  Pdt  can  be  interpolated  based  on  the  actual 
3dB  dwell  time  produced  by  the  radar  scan.  This  technique  effectively  reverses  the  Joint  STARS 
engineering  process  of  solving  for  dwell  time  given  a  desired  Pd.  Once  Pdt  is  found,  radial  velocity  dips 
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due  to  PRF  blinds  will  be  applied.  The  RPS  shall  [36]  have  a  Pd  versus  radial  velocity  curve  (figure 
3.2-5)  for  each  waveform  identifier  developed  offline  as  per  section  (3.2.2.2.4).  Since  the  stracture  of 
the  radial  velocity  dips  do  not  change  for  various  Pd  levels,  the  actual  target  Pd  (Pdt)  wiU  be  determined 
for  Pdt  and  the  Pd  versus  radial  velocity  cmve,  by  effectively  moving  the  curve  up  or  down  so  that  its 
average  Pd  is  the  same  as  Pdt.  The  radial  velocity  Pd  dips  are  attenuated  when  increasing  the  average 
Pd  and  enhanced  when  reducing  the  average  Pd  through  use  of  a  range  rate  dip  factor  (^). 

As  a  minimum,  virtual  target  Pd  (Pdt)  shall  [37]  be  derived  fi'om  the  following  information: 

•  Scan  conditions  (3 .2.2.2. 1) 

-  Azimuth :  expand  dwell  time  by  azimuth,  figure  3.2-3. 

-  Range  coverage  :  expand  dwell  time  by  range,  figure  3.2-4. 

-  3dB  beam  dwell  time  :  apply  Pd  factor  to  dwell  time,  figure  3.2-5. 

-  Waveform  identifier :  select  nominal  Pd  vs  Velocity  curve,  figure  3.2-6. 

•  Environmental  factors  (3.2.2.2.2) 

-  Weather  loss  :  interpolate  Lagrange  coefficients  between  S/N  levels. 

-  Terrain  :  targets  obscured  by  terrain  cannot  be  detected  (Pd  =  0). 

•  Virtual  target  geometry  (3.2.2.2.3. 1) 

-  Azimuth  :  for  Pd  purposes,  target  azimuth  may  be  assumed  to  be  the  same  as 
beam  dwell  azimuth,  since  the  azimuth  beamwidth  is  relatively  small. 

-  Range  :  solve  for  dwell  time  based  on  range  coverage  curve,  figure  3.2-4. 

-  Radial  velocity  :  Pdt  =  Pdt  +  Rf  x  (Pdn  -  Pdr) 

*  Pdt  is  the  Pd  of  the  virtual  target  at  radial  velocity  V. 

*  Pdt  is  the  Pd  of  the  virtual  target  averaged  over  all  radial  velocities. 

*  Rf  is  the  range  rate  factor  used  to  attenuate  /  enhance  Pd  dips. 

*  Pdrt  is  the  Pd  of  the  reference  curve  at  radial  velocity  V. 

*  Pdr  is  the  Pd  of  tire  reference  curve  averaged  over  all  radial  velocities. 

•  Target  resolution  (3.2.2.2.3.4) 
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30B  DWELL  TIME  (SEC) 


Figure  3.2-3.  Expand  Dwell  Time  by  Azimuth  (at  Minimum  Range) 


Figure  3.2-4.  Expand  Dwell  Time  by  Range  (at  Dwell  Azimuth) 
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Figure  3.2-5.  Apply  Pd  Factor  to  DweU  Time 


Figure  3.2-6.  Apply  Radial  Velocity  Dips 
3.2.2.2.3.6  Probability  of  False  Alarm  (PFA) 

RSR  receiver  threshold  levels  shall  [38]  be  considered  to  increase  or  decrease  the  nominal  PFA 
required  by  the  Joint  STARS  System  Specification.  False  virtual  targets  will  be  placed  randomly  in 
range  and  azimuth  within  the  radar  beam  dwell  (32.2.2. 1)  after  all  virtual  targets  have  been  considered. 
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2)2223.1  Target  Classification  (TC) 


A  TC  of  wheeled  or  tracked  will  be  determined  based  on  the  probability  of  detecting  the  double 
doppler  component.  Since  the  double  doppler  component  is  significantly  smaller  than  the  actual  target, 
determination  of  virtual  target  TC  shall  [39]  be  accomphshed  like  Pd  (3.2.2.2.3.5)  such  that  TC 
represents  an  additional  S/N  loss.  Virtual  target  TC  results  will  be  appHed  after  PSP  Node  2 
processing  has  been  completed. 

3.2.2.2.4  Modeling 

A  set  of  radar  operating  curves  shall  [40]  be  developed  for  the  real-time  Mil  Simulation  which  relates 
MTI  Pd  (3.2.2.2.3.5)  and  CEP  (3.2.2.2.3.3)  statistics  as  a  fiiction  of  target  S/N.  These  curves  will  be 
developed  primarily  firom  non-real-time  Joint  STARS  simulations  and  tempered  by  empirical  results 
obtained  through  flight  test  conditions.  This  approach  enables  the  real-time  Mil  simulation  to  emulate 
the  statistical  tendencies  of  the  Joint  STARS  radar  over  the  infinite  set  of  possible  scan  conditions 
encountered  in  the  real  world.  The  radar  operating  curves  will  be  developed  under  baseline  conditions 
of  clear  weather  (3.2.2.2.2.1),  for  a  nominal  sized  target  (3.2,2.2.3.2),  from  which  S/N  variations  will 
be  interpolated. 

3.2.3  SAR  Imagery  Simulation 

The  SAR  Imagery  simulation  shall  [41]  receive  as  input  fix)m  the  RPS  Control  function  (3.2.1)  the  SAR 
beam  dwell  data  and  the  stationary  virtual  targets  received  over  the  DIS  network.  The  stationary  virtual 
targets  will  be  geometrically  filtered,  modeled  according  to  Joint  STARS  SAR  resolution  capabilities 
and  mixed  with  the  virtual  terrain  features  within  flie  SAR  features  database.  Requests  for  SAR  or  FTI 
service  shall  [42]  be  considered  a  virtual  SAR/FTI  request  if  the  central  reference  point  (CRP)  defining 
the  SAR/FTI  AOI  falls  within  the  virtual  area.  FTI  processing  will  be  a  thresholded  version  of  SAR 
Imagery  processing. 

3.2.3. 1  SAR  Imagery  Control 

***  TBD  pending  LORAL  contract  status*** 

3. 2. 3. 2  SAR  Imagery  Processing 

***  TBD  pending  LORAL  contract  status*** 

3.2.4  Stand  Alone  Mode 

The  RPS  shall  [43]  be  capable  of  executing  in  a  simulation  only  mode,  referred  to  as  the  Stand  Alone 
mode,  such  that  the  RPS  functions  in  the  same  manner  as  during  flight  mode,  but  without  live  data 
inputs.  This  mode  requires  all  Joint  STARS  PME  except  those  contained  in  the  radar  sensor  group 
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(RSG),  Programmable  Signal  Processors  (PSP),  and  the  Navigation  subsystem.  The  interfaces  with  the 
missing  PME  wiU  be  simulated  in  real-time  as  defined  in  the  following  subsections. 

3.2.4. 1  Radar  Control  Simulation 

The  radar  AUX  data  containing  sensor  commands  used  by  the  radar  during  each  CPI  shall  [44]  be 
simulated  based  upon  the  commands  given  in  the  Primary  Mode  Control  (PMC)  message  sent  by  the 
RDP  for  each  radar  beam  dwell.  All  other  messages  normally  sent  to  or  from  the  Radar  Control  Unit 
(RCU)  on  the  1553  Radar  Sensor  Bus  (RSB)  wiU  be  modeled  for  nominal  conditions  without  errors 
induced.  Radar  Sensor  IQ  outputs  will  not  be  modeled. 

3. 2. 4. 2  PSP  Simulation 

The  PSP  setup  /  acknowledge,  node  1  and  node  2  communication  paths  with  the  RDP  on  the  PSP 
LAN  shall  [45]  be  modeled  based  on  the  RDP  inputs.  No  live  targets  or  discretes  will  be  simulated, 
and  a  nominal  clutter  environment  will  be  used.  All  other  messages  normally  sent  to  or  fi'om  the  PSP  on 
the  PSP  LAN  will  be  modeled  for  nominal  conditions  without  errors  induced.  Radar  sensor  IQ  inputs 
will  not  be  modeled. 

3.2. 4.3  Navigation  Simulation 

The  navigation  data  normally  produced  by  the  Joint  STARS  FMP  CPCI  Relative  Navigation  function 
shall  [46]  be  simulated  by  the  RPS.  The  navigation  data  contains  platform  position,  velocity  and  attitude 
data  as  a  function  of  time,  and  is  output  at  a  10  Hz  rate.  The  Navigation  simulation  will  support  a 
racetrack,  figure  eight,  random,  or  circular  orbit  based  on  the  contents  of  a  navigation  simulation  file 
provided  upon  initialization  of  the  RPS. 
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4.  Quality  Assurance 


The  contractor  will  be  responsible  for  maintaining  the  RPS  software  xmder  a  configuration  management 
system  comparable  with  that  developed  for  Joint  STAES.  The  contractor  will  be  responsible  for 
verification  of  the  RPS  requirements  and  for  justifying  the  selected  methods  of  verification.  The 
contractor  will  formulate  a  separate  verification  and  validation  plan  for  the  E-8C  RPS.  The  methods  of 
verification  will  be  by  inspection,  analysis,  demonstration,  or  test. 
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5.  Definitions 


Provided  in  this  section  is  a  summary  of  acronyms  used  in  this  report. 

•  AOI :  Area  of  Interest 

•  ATWS  :  Advanced  Tactical  Work  Station 

•  CEP  :  Circular  Error  Probable 

•  CPI :  Coherent  Processing  Interval 

•  DIS  :  Distributed  Interactive  Simulation 

•  DISNIU :  DIS  Network  Interface  Unit 

•  ECEF  :  Earth  Centered  Earth  Fixed 

•  ES  PDU :  Entity  State  Protocol  Data  Unit 

•  GPC  :  General  Purpose  Computer 

•  Joint  STARS  :  Joint  Surveillance  Target  Attack  Radar  System 

•  LAN  :  Local  Area  Network 

•  LAOI :  Live  AOI 

•  MTI :  Moving  Target  Indicator 

•  PFA :  Probability  of  False  Alarm 

•  Pd :  Probability  of  Detection 

•  PSP  :  Programmable  Signal  Processor 

•  RCU :  Radar  Control  Unit 

•  RDO  :  Radar  Data  Operational 

•  RDP  :  Radar  Data  Processor 

•  RPS  ;  Radar  Processor  Simulation 

•  RSB  :  Radar  Sensor  Bus 

•  RSG ;  Radar  Sensor  Group 

•  RSR :  Radar  Service  Request 

•  S  /  N  :  Signal-to-Noise  Ration 

•  SAR :  Synthetic  Aperture  Radar 

•  TC  ;  Target  Classification 

•  TCS  :  Topocentric  Coordinate  System 

•  WAN  :  Wide  Area  Network 

•  WGS-84  :  World  Geographic  System  1984 
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References 


[1]  3.1.  Hardware  Requirements.  Inspection.  Under  normal  conditions,  the  RPS  shaU  consist  of  two 
distinct  architectures,  one  on  the  ground  (3.1.3)  interfacing  with  the  DIS  network,  and  one  on¬ 
board  the  Joint  STARS  platform  (3.1.4)  perfoiming  the  MTI  and  SAR  Imagery  simulations. 

[2]  3.1.  Hardware  Requirements.  Demonstration.  These  two  architectures  shall  be  connected  by  an 
RF  Link  (3.1 .2)  during  flight  mode  and  with  a  LAN  while  in  the  lab  environment. 

[3]  3.1.1.  Joint  STARS  Configuration.  Inspection.  The  RPS  shall  be  developed  for  incorporation  into 
the  third  aircraft  configuration  used  for  low  rate  initial  production  of  the  E-8C  Joint  STARS. 

[4]  3.1.3.  Down  Link  Architecture.  Test.  The  down  link  architecture  shall  be  capable  of  logging 
PDUs  for  future  data  analysis  and  test  purposes. 

[5]  3.1.4.  Up  Link  Architecture.  Inspection.  The  up  link  processes  developed  for  the  RPS  shall  be 
hosted  in  one  or  more  of  the  Joint  STARS  general  puipose  computers  (GPC)  on  board  the 
platform. 

[6]  3. 2. 1.1.1.  Identify  Live  AOIs.  Test.  Within  these  LAOIs,  only  “live”  targets  detected  by  Joint 
STARS  shall  be  reported. 

[7]  3.2. 1 . 1 . 1 .  Identify  Live  AOIs.  Test.  Outside  of  these  LAOIs,  only  ‘Virtual”  targets  supplied  to  the 
RPS  shall  be  reported. 

[8]  3. 2. 1.1.1.  Identify  Live  AOIs.  Demonstration.  The  RPS  shall  maintain  up  to  four  LAOIs. 

[9]  3.2. 1 . 1 . 1 .  Identify  Live  AOIs.  Inspection.  The  set  of  LAOIs  shall  be  provided  by  the  customer  as 
a  file  to  be  read  in  upon  initialization  of  the  RPS  and  cannot  be  modified  during  the  JADS  exercise. 

[10]  3.2. 1.1.2.  Identify  Hypso  and  Carto  Database.  Inspection.  The  hypsographic  and  cartographic 
databases  defining  the  features  of  the  Joint  STARS  primaiy  region  shall  be  replaced  upon 
initialization  of  the  RPS  with  a  new  set  of  databases  incorporating  the  virtual  features  for  the  JADS 
mission. 

[11]  3. 2. 1.2.  Operator  Controls.  Test.  The  RPS  operator  shall  be  given  modest  control  of  simulation 
parameters  through  the  use  of  flags  and  thresholds. 

[12]  3. 2. 1.3.  DIS  Interface  Control.  Inspection.  The  RPS  control  function  shall  receive  ES  PDUs 
over  the  DIS  network  and  maintain  a  database  of  those  ES  PDUs  applicable  to  the  Joint  STARS 
mission. 
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[13]  3.2. 1.3.1.  DIS  Network.  Inspection.  ES  PDUs  shall  be  managed  in  two  separate  architectures, 
one  on  the  ground  connected  to  the  DIS  network,  referred  to  as  DISNIU  I,  and  a  second  on  the 
platform  connected  to  the  Joint  STARS  OWS  and/or  PSP  LAN,  referred  to  as  DISNIU  II. 

[14]  3.2. 1.3.1.  DIS  Network.  Inspection.  DISNIU  I  shall  use  the  TCP/IP  UDP  protocol  for 
communication  on  the  DIS  network. 

[15]  3.2.I.3.2.  Receive  Entity  State  PDUs.  Inspection.  The  RPS  shall  be  required  to  maintain  at  least 
5000  virtual  targets,  with  a  growth  capacity  of  at  least  20000  virtual  targets. 

[16]  3.2.I.3.2.  Receive  Entity  State  PDUs.  Test.  Virtual  targets  shall  be  deleted  by  the  RPS  when  the 
war-games  simulation  issues  a  Remove  Entity  PDU  or  if  “deactivated”  by  an  ES  PDU. 

[17]  3.2.I.3.3.  Coordinate  Conversion.  Inspection.  ES  PDU  position  and  velocity  shall  be  converted 
from  ECEF  to  the  Joint  STARS  Topocentric  Coordinate  System  (TCS)  by  DISNIU  I  in  order  to 
save  processor  load  for  the  Real-time  MTI  (3.2.2)  and  SAR  Imageiy  (3.2.3)  simulations  on  the 
platform. 

[18]  3.2.I.3.3.  Coordinate  Conversion.  Inspection.  ES  PDU  orientation  shall  be  converted  from  the 
entity  coordinate  system  to  TCS  by  DISNIU  I. 

[19]  3.2.I.3.4.  Filter  Entity  State  PDUs.  Analysis.  ES  PDU  information  applicable  to  the  MTI  and 
SAR  Imagery  simulations  shall  be  reduced  to  flie  minimum  amount  of  information  required  by  the 
real-time  simulations  in  order  to  minimize  the  use  of  the  available  RE  Link  bandwidth. 

[20]  3. 2. 1.3 .4.  Filter  Entity  State  PDUs.  Test.  ES  PDU  filtering  shall  be  performed  on  a  maximum 
sustained  rate  of  100  virtual  target  updates  per  second  plus  the  heartbeat  rate. 

[21]  3.2.I.3.5.  Dead  Reckoning.  Inspection.  Virtual  targets  received  by  DISNIU  11  shall  be 
extrapolated  to  current  time  at  a  minimum  rate  of  5  Hz  using  a  first  order  position  update  (P  =  Po  + 
VAT). 

[22]  3.2.I.3.6.  Joint  STARS  Entity  State  PDU.  Test.  The  Joint  STARS  state  message  shall  be  sent  at 
a  1  Hz  rate  by  DISNIU  II  and  output  over  the  DIS  network  by  DISNIU  I  when  the  dead  reckoned 
platform  position  varies  by  more  than  the  operator  specified  Joint  STARS  position  threshold,  or  its 
heartbeat  timer  has  expired. 

[23]  3.2.2.  MTI  Simulation.  Test  The  virtual  targets  shall  be  geometrically  filtered,  have  MU  statistics 
applied,  and  mixed  with  the  appropriate  live  targets  for  output  from  the  radar  subsystem. 
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[24]  3.2.2.  MTI  Simulation.  Test.  The  processing  required  by  the  MTI  simulation  shall  not  degrade 
the  radar  timeline  beyond  the  nominal  timeline  fluctuations  experienced  by  the  Joint  STARS  radar 
under  heavy  target  load  conditions. 

[25]  3.2.2. 1.  MIT  Control.  Inspection.  The  MTI  control  function  shall  determine  those  virtual  targets 
within  the  current  beam  dwell  footprint  but  not  within  the  LAOIs. 

[26]  3.2.2. 1.3.  Filter  Live  Targets.  Test.  Only  those  live  targets  which  reside  inside  a  LAOI  shall  be 
considered  “detected”  by  the  RPS. 

[27]  3. 2.2. 1.4.  Filter  Virtual  Targets.  Test.  Only  tiiose  virtual  targets  which  reside  outside  the  LAOIs 
(aka  virtual  area)  and  within  the  current  radar  beam  dwell  footprint  shall  be  considered  for  possible 
“detection”  by  the  RPS. 

[28]  3.2.2. 1.5.  Mix  Live  and  Virtual  Targets.  Demonstration.  For  each  radar  beam  dwell,  the 
detected  live  moving  targets  (3.2.2.L3)  and  the  detected  virtual  moving  targets  (3.2.22)  shall  be 
merged  into  a  single  dwell  report  representing  a  mix  of  live  and  virtual  targets  within  the  same  beam, 
but  not  overlapping  in  physical  space. 

[29]  3. 2.2.2.  MTI  Processing.  Demonstration.  After  the  MTI  control  function  (3.2.2. 1)  filters  the 
virtual  targets  based  on  beam  dwell  and  LAOI  geometry,  this  simulation  shall  create  a  subset  of 
these  virtual  targets  which  exhibit  similar  characteristics  as  live  Joint  STARS  targets  would  under  the 
same  scan  conditions. 

[30]  3.2.2.2.2.I.  Weather.  Inspection.  Weather  conditions  shall  be  assumed  to  be  one  of  three 
categories;  (1)  clear;  (2)  cloud;  (3)  rain;  as  defined  in  the  Joint  STARS  System  Specification,  as 
selected  by  the  JADS  operator  (3.2. 1.2). 

[3 1]  3.2.2.2.2.2.  Refinction.  Inspection.  The  method  employed  by  Joint  STARS  to  determine  the 
range  refiuction  correction  shall  be  used  by  the  RPS  to  enhance  symmetry  between  live  an  virtual 
targets. 

[32]  3.2.2.2.2.3  Terrain.  Test.  The  RPS  shall  identify  those  virtual  targets  obscured  by  terrain  based 
on  the  hypsographic  database,  and  the  current  platform  position  along  the  radar  beam’s  line  of  sight. 

[33]  3.2.2.2.3.  Virtual  Target  Statistics.  Inspection.  MTI  statistics  shall  be  applied  stochastically  to  the 
virtual  targets  using  a  uniformly  distributed  random  number  sequence  in  order  to  effectively  simulate 
virtual  targets  as  Joint  STARS  targets. 

[34]  3.2.2.2.3.3.  Location  Accuracy.  Test.  Once  the  down  range  and  cross  range  error  has  been 
established,  these  values  shall  be  applied  to  the  position  vector  (Pt)  of  the  target. 
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[35]  3.2.2.23.5.  Probability  of  Detection  (Pd).  Analysis.  Radar  operating  curves  (3.2.2.2.4)  shall  be 
developed  offline  which  relate  the  radar  beam  dwell  time  to  the  Joint  STARS  azimuth  (figure  3.2-3) 
and  range  (figure  3.2-4)  constraints  for  a  family  of  Pd  and  S  /  N  levels. 

[36]  3.2.2.2.3.5.  Probability  of  Detection  (Pd).  Analysis.  The  RPS  shall  have  a  Pd  versus  radial 
velocity  curve  (figure  3.2-5)  for  each  waveform  identifier  developed  off  line  as  per  section 
(3.2.2.2.4). 

[37]  3.2.2.2.3.5.  Probability  of  Detection  (Pd).  Test.  As  a  minimiun,  virtual  target  Pd  (Pdt)  shall  be 
derived  fi'om  the  following  information;  Scan  conditions  (3 .2.2.2. 1),  Environmental  factors 
(3.2.2.2.2),  Virtual  target  geometry  (3.2.2.2.3.1),  and  Target  resolution  (3.2.2.2.3.4). 

[38]  3.2.2.2.3.6.  Probability  of  False  Alarm  (PFA).  Test)  RSR  receiver  threshold  levels  shall  be 
considered  to  increase  or  decrease  the  nominal  PFA  required  by  the  Joint  STARS  System 
Specifications. 

[39]  3.2.2.2.3.I.  Target  Classification  (TC).  Analysis.  Since  the  double  doppler  component  is 
significantly  smaller  than  the  actual  target,  determination  of  virtual  target  TC  shall  be  accomplished 
like  Pd  (3.2.2.2.3.5)  such  that  TC  represents  and  additional  S  /  N  loss. 

[40]  3.2.2.2.4.  Modeling.  Analysis.  A  set  of  radar  operating  curves  shall  be  developed  for  the  real¬ 
time  MTI  Simulation  which  relates  MTI  Pd  (3.2.2.2.3.5)  and  CEP  (3.2.2.2.3.3)  statistics  as  a 
function  of  target  S  /  N. 

[41]  3.2.3.  Sar  Imagery  Simulation.  Demonstration.  The  SAR  Imagery  simulation  shall  receive  as 
input  fi:om  the  RPS  Control  function  (3.2.1)  the  SAR  beam  dwell  data  and  the  stationary  virtual 
targets  received  over  the  DIS  network. 

[42]  3.2.3.  SAR  Imagery  Simulation.  Test.  Requests  for  SAR  or  FTI  service  shall  be  considered  a 
virtual  SAR  /  FTI  request  if  the  central  reference  point  (CRP)  defining  the  SAR  /  FTI  AOI  falls 
within  the  virtual  area. 

[43]  3.2.4.  Stand  Alone  Mode.  Demonstration.  The  RPS  shall  be  capable  of  executing  in  a  simulation 
only  mode,  referred  to  as  the  Stand  Alone  mode,  such  that  the  RPS  functions  in  the  same  manner  as 
during  flight  mode,  but  without  live  data  inputs. 

[44]  3.2.4. 1.  Radar  Control  Simulation.  Demonstration.  The  radar  AUX  data  containing  sensor 
commands  used  by  the  radar  during  each  CPI  shall  be  simulated  based  upon  the  commands  given  in 
the  Primary  Mode  Control  (PMC)  message  sent  by  the  RDP  for  each  radar  beam  dwell. 

[45]  3.2.4.2.  PSP  Simulation.  Demonstration.  The  PSP  setup  /  acknowledge,  node  1,  and  node  2 
communication  paths  with  the  RDP  on  the  PSP  LAN  shall  be  modeled  based  on  the  RDP  inputs. 
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[46]  3.2.43.  Navigation  Simulation.  Demonstration.  The  navigation  data  nonnally  produced  by  the 
Joint  STARS  FMP  CPCI  Relative  Navigation  function  shall  be  simulated  by  the  RPS. 
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PRELIMINARY 


Verification  Cross  Reference  Matrix  (VC; 

RM) 

Item 

Paragraph  Title 

Method 

Requirement 

1 

3.1 

Hardware  Requirements 

Inspection 

Under  normal  conditions,  the  RPS  shall 
consist  of  two  distinct  architectures,  one  on 
the  ground  (3.1.3)  interfacing  with  the  DIS 
network,  and  one  on-board  the  Joint  STARS 
platform  (3.1.4)  performing  the  MTI  and 

SAR  Imagery  simulations. 

2 

3.1 

Hardware  Requirements 

Demonstration 

These  two  architectures  shall  be  connected 
by  an  RF  Link  (3.1.2)  during  flight  mode  and 
with  a  LAN  while  in  the  lab  environment. 

3 

3.1.1 

Joint  STARS  Configuration 

Inspection 

The  RPS  shall  be  developed  for 
incorporation  into  the  third  aircraft 
configuration  used  for  low  rate  initial 
production  of  the  E-8C  Joint  STARS. 

4 

3.1.3 

Down  Link  Architecture 

Test 

The  down  link  architecture  shall  be  capable 
of  logging  PDUs  for  future  data  analysis 
and  test  purposes. 

5 

3.1.4 

Up  Link  Architecture 

Inspection 

The  up  link  processes  developed  for  the 

RPS  shall  be  hosted  in  one  or  more  of  the 
Joint  STARS  general  purpose  computers 
(GPC)  on  board  the  platform. 

6 

3.2.1. 1.1 

Identify  Live  AOIs 

Test 

Within  these  LAOIs,  only  “live”  targets 
detected  by  Joint  STARS  shall  be  reported. 

7 

3.2.1.1.1 

Identify  Live  AOIs 

Test 

Outside  of  these  LAOIs,  only  “virtual” 
targets  supplied  to  the  RPS  shall  be 
reported. 

00 

3.2.1.1.1 

Identify  Live  AOIs 

Demonstration 

The  RPS  shall  maintain  up  to  four  LAOIs. 

9 

3.2.1.1.1 

Identify  Live  AOIs 

Inspection 

The  set  of  LAOIs  shall  be  provided  by  the 
customer  as  a  file  to  be  read  in  upon 
initialization  of  the  RPS  and  cannot  be 
modified  during  the  JADS  exercise. 

10 

3.2.1.1.2 

Identify  Hypso  and  Carto 
Database 

Inspection 

The  hypsographic  and  cartographic 
databases  defining  the  features  of  the  Joint 
STARS  primary  region  shall  be  replaced 
upon  initialization  of  the  RPS  with  a  new  set 
of  databases  incorporating  the  virtual 
features  for  the  JADS  mission. 

11 

3.2.1.2 

Operator  Controls 

Test 

The  RPS  operator  shall  be  given  modest 
control  of  simulation  parameters  through 
the  use  of  flags  and  thresholds. 
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Item 

Paragraph 

Paragraph  Title 

Method 

Requirement 

12 

3.2.1.3 

DIS  Interface  Control 

Inspection 

The  RPS  control  function  shall  receive  ES 
PDUs  over  the  DIS  network  and  maintain  a 
database  of  those  ES  PDUs  applicable  to 
the  Joint  STARS  mission. 

13 

3.2.1.3.1 

DIS  Network 

Inspection 

ES  PDUs  shall  be  managed  in  two  separate 
architectures,  one  on  the  ground  connected 
to  the  DIS  network,  referred  to  as  DISNIU  I, 
and  a  second  on  the  platform  connected  to 
the  Joint  STARS  OWS  and/or  PSP  LAN, 
referred  to  as  DISNIU  II. 

14 

3.2.1.3.1 

DIS  Network 

Inspection 

DISNIU  I  shall  use  the  TCP/IP  UDP  protocol 
for  communication  on  the  DIS  network. 

15 

3.2.L3.2 

Receive  Entity  State  PDUs 

Inspection 

The  RPS  shall  be  required  to  maintain  at 
least  5000  virtual  targets,  with  a  growth 
capacity  of  at  least  20000  virtual  targets. 

16 

3,2.13.2 

Receive  Entity  State  PDUs 

Test 

Virtual  targets  shall  be  deleted  by  the  RPS 
when  the  war-games  simulation  issues  a 
Remove  Entity  PDU  or  if  “deactivated”  by 
an  ES  PDU. 

17 

3,2.1.33 

Coordinate  Conversion 

Inspection 

ES  PDU  position  and  velocity  shall  be 
converted  from  ECEF  to  the  Joint  STARS 
Topocentric  Coordinate  System  (TCS)  by 
DISNIU  I  in  order  to  save  processor  load  for 
the  Real-time  MTI  (3.2.2)  and  SAR  Imagery 
(3.2.3)  simulations  on  the  platform. 

18 

3.2.13.3 

Coordinate  Conversion 

Inspection 

ES  PDU  orientation  shall  be  converted  from 
the  entity  coordinate  system  to  TCS  by 
DISNIU  I. 

19 

3.2.13.4 

Filter  Entity  State  PDUs 

Analysis 

ES  PDU  information  applicable  to  the  MTI 
and  SAR  Imagery  simulations  shall  be 
reduced  to  the  minimum  amount  of 
information  required  by  the  real-time 
simulations  in  order  to  minimize  the  use  of 
the  available  RF  Link  bandwidth. 
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Item 

Paragraph 

Paragraph  Title 

Method 

Requirement 

20 

3.2.1.3.4 

Filter  Entity  State  PDUs 

Test 

ES  PDU  filtering  shall  be  performed  on  a 
maximum  sustained  rate  of  100  virtual  target 
updates  per  second  plus  the  heartbeat  rate. 

21 

3.2.1. 3.5 

Dead  Reckoning 

Inspection 

Virtual  targets  received  by  DISNIU  II  shall 
be  extrapolated  to  current  time  at  a  minimum 
rate  of  5  Hz  using  a  first  order  position 
update  (P  =  Po  +  VAT). 

22 

3.2.1.3.6 

Joint  STARS  Entity  State  PDU 

Test 

The  Joint  STARS  state  message  shall  be 

sent  at  a  1  Hz  rate  by  DISNIU II  and  output 
over  the  DIS  network  by  DISNIU  I  when  the 
dead  reckoned  platform  position  varies  by 
more  than  the  operator  specified  Joint 
STARS  position  threshold,  or  its  heartbeat 

_ timer  has  expired.  _ 

23  3.2.2  MTI  Simulation  Test  The  virtual  targets  shall  be  geometrically 

filtered,  have  MTI  statistics  applied,  and 
mixed  with  the  appropriate  live  targets  for 
_ output  from  the  radar  subsystem. _ 

24  3,2.2  MTI  Simulation  Test  The  processing  required  by  the  MTI 

simulation  shall  not  degrade  the  radar 
timeline  beyond  the  nominal  timeline 
fluctuations  experienced  by  the  Joint 
STARS  radar  under  heavy  target  load 
conditions.  _ _ 


26  3.2.2.1.3 


MTI  Control 

Filter  Live  Targets 


Inspection  The  MTI  control  function  shall  determine 

those  virtual  targets  within  the  current  beam 

_ dwell  footprint  but  not  within  the  LAOIs. 

Test  Only  those  live  targets  which  reside  inside  a 

LAOI  shall  be  considered  “detected”  by  the 
RPS.  _ 


27 

3.2.2.L4 

Filter  Virtual  Targets 

Test 

Only  those  virtual  targets  which  reside 
outside  the  LAOIs  (aka  virtual  area)  and 
within  the  current  radar  beam  dwell  footprint 
shall  be  considered  for  possible  “detection” 
by  the  RPS. 

28 

3.2.2.1.5 

Mix  Live  and  V irtual  T argets 

Demonstration 

For  each  radar  beam  dwell,  the  detected  live 
moving  targets  (3.2.2. 1 .3)  and  the  detected 
virtual  moving  targets  (3. 2.2. 2)  shall  be 
merged  into  a  single  dwell  report 
representing  a  mix  of  live  and  virtual  targets 
within  the  same  beam,  but  not  overlapping 
in  physical  space. 

29 

3.2.2.2 

MTI  Processing 

Demonstration 

After  the  MTI  control  function  (3.2.2. 1) 

filters  the  virtual  targets  based  on  beam 
dwell  and  LAOI  geometry,  this  simulation 
shall  create  a  subset  of  these  virtual  targets 
which  exhibit  similar  characteristics  as  live 
Joint  STARS  targets  would  under  the  same 
scan  conditions. 
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Item 

Paragraph 

Paragraph  Title 

Method 

Requirement 

30 

3.2.2.2.2.1 

Weather 

Inspection 

Weather  conditions  shall  be  assumed  to  be 
one  of  three  categories;  (1)  clear;  (2)  cloud; 

(3)  rain;  as  defined  in  the  Joint  STARS 

System  Specification,  as  selected  by  the 

JADS  operator  (3. 2. 1.2). 

31 

Refraction 

Inspection 

The  method  employed  by  Joint  STARS  to 
determine  the  range  refraction  correction 
shall  be  used  by  the  RPS  to  enhance 
symmetry  between  live  an  virtual  targets. 

32 

3.2.2.2.23 

Terrain 

Test 

The  RPS  shall  identify  those  virtual  targets 
obscured  by  terrain  based  on  the 
hypsographic  database,  and  the  current 
platform  position  along  the  radar  beam’s 
line  of  sight. 
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3.2.2.23 

Virtual  Target  Statistics 

Inspection 

MTI  statistics  shall  be  applied 
stochastically  to  the  virtual  targets  using  a 
uniformly  distributed  random  number 
sequence  in  order  to  effectively  simulate 
virtual  targets  as  Joint  STARS  targets. 
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3.2.2.233 

Location  Accuracy 

Test 

Once  the  down  range  and  cross  range  error 
has  been  established,  these  values  shall  be 
applied  to  the  position  vector  (Pt)  of  the 
target. 
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3.2.2.23.5 

Probability  of  Detection  (Pd) 

Analysis 

Radar  operating  curves  (3.2.2.2,4)  shall  be 
developed  offline  which  relate  the  radar 
beam  dwell  time  to  the  Joint  STARS  azimuth 
(figure  3.2-3)  and  range  (figure  3.2-4) 
constraints  for  a  family  of  Pd  and  S/N  levels. 
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3.2.2.23.5 

Probability  of  Detection  (Pd) 

Analysis 

The  RPS  shall  have  a  Pd  versus  radial 
velocity  curve  (figure  3.2-5)  for  each 
waveform  identifier  developed  offline  as  per 
section  (3.2.2.2.4). 
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3.2.2.23.5 

Probability  of  Detection  (Pd) 

Test 

As  a  minimum,  virtual  target  Pd  (Pdt)  shall 
be  derived  from  the  following  information; 
Scan  conditions  (3.2.2.2.1),  Environmental 
factors  (3.2.2.2.2),  Virtual  target  geometry 
(3.2.2.2.3. 1),  and  Target  resolution 
(3.2.2.23.4). 
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3.2.2.23.6 

Probability  of  False  Alarm  (PFA) 

Test 

RSR  receiver  threshold  levels  shall  be 
considered  to  increase  or  decrease  the 
nominal  PFA  required  by  the  Joint  STARS 
System  Specifications. 
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3.2.2.2.3.7 

Target  Classification  (TC) 

Analysis 

Since  the  double  doppler  component  is 
significantly  smaller  than  the  actual  target, 
determination  of  virtual  target  TC  shall  be 
accomplished  like  Pd  (3.2.2.2.3.5)  such  that 

TC  represents  and  additional  S/N  loss. 

3.2.2.2.4 

Modeling 

Analysis 

A  set  of  radar  operating  curves  shall  be 
developed  for  the  real-time  MTI  Simulation 
which  relates  MTI  Pd  (3.2.2.2.3.5)  and  CEP 
(3. 2.2.2. 3. 3)  statistics  as  a  function  of  target 
S/N. 
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Item 

Paragraph  Title 

Method 

Requirement 
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3.2.3 

SAR  Imagery  Simulation 

Demonstration 

The  SAR  Imagery  simulation  shall  receive 
as  input  from  the  RPS  Control  function 
(3.2.1)  the  SAR  beam  dwell  data  and  the 
stationary  virtual  targets  received  over  the 
DIS  network. 
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3.2.3 

SAR  Imagery  Simulation 

Test 

Requests  for  SAR  or  FTI  service  shall  be 
considered  a  virtual  SAR  /  FTI  request  if  the 
central  reference  point  (CRP)  defining  the 

SAR  /  FTI  AOI  falls  within  the  virtual  area. 
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3.2.4 

Stand  Alone  Mode 

Demonstration 

The  RPS  shall  be  capable  of  executing  in  a 
simulation  only  mode,  referred  to  as  the 

Stand  Alone  mode,  such  that  the  RPS 
functions  in  the  same  manner  as  during 
flight  mode,  but  without  live  data  inputs. 
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3.2.4, 1 

Radar  Control  Simulation 

Demonstration 

The  radar  AUX  data  containing  sensor 
commands  used  by  the  radar  during  each 

CPI  shall  be  simulated  based  upon  the 
commands  given  in  the  Primary  Mode 

Control  (PMC)  message  sent  by  the  RDP  for 
each  radar  beam  dwell. 
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3.2.4.2 

PSP  Simulation 

Demonstration 

The  PSP  setup  /  acknowledge,  node  1,  and 
node  2  communication  paths  with  the  RDP 
on  the  PSP  LAN  shall  be  modeled  based  on 
the  RDP  inputs. 
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3.2.4.3 

Navigation  Simulation 

Demonstration 

The  navigation  data  normally  produced  by 
the  Joint  STARS  FMP  CPCI  Relative 
Navigation  function  shall  be  simulated  by 
the  RPS. 
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ABSTRACT 

The  End-To-End  Test  (ETE)  is  being  conducted  under  the  auspices  of  the  Department  of  Defense  Joint 
Advanced  Distributed  Simulation  (JADS)  Joint  Test  and  Evaluation  (JT&E).  The  purpose  of  the  ETE  is 
to  investigate  the  utility  of  using  advanced  distributed  simulation  (ADS)  to  augment  both  developmental 
and  operational  testing  of  the  Joint  STARS  surveillance  system.  The  basic  concept  behind  the  ETE  is  to 
augment  the  Joint  STARS  environment  with  a  virtual  environment  created  by  thousands  of  simulated 
entities,  or  targets.  This  virtual  environment  is  imaged  by  simulations  of  the  radar  systems  contained 
within  the  Joint  STARS  E-8C  aircraft  and  mixed  with  real  radar  returns  to  provide  a  robust  operational 
environment  for  testing  of  the  system. 

The  ETE  Joint  STARS  simulation  is  called  the  Virtual  Surveillance  Target  Attack  Radar  System 
(VSTARS).  Simulated  entities  are  transmitted  to  VSTARS  through  the  use  of  Entity  State  Protocol 
Data  Units  (ESPDU).  The  simulation,  or  simulations,  representing  these  entities  transmit  ESPDUs 
representing  the  status  of  each  entity.  This  status  is  used  to  update  data  bases  that  are  used  to  generate 
Joint  STARS  virtual  radar  images.  Two  modifications  have  been  made  to  the  ESPDU  for  use  in  the 
ETE.  The  first  of  these  is  a  modification  of  the  time  field  and  is  not  mandatory,  but  is  recommended.  It 
records  the  time  the  ESPDU  was  created  since  the  start  of  the  simulation  scenario.  The  second  change 
to  the  ESPDU  is  performed  internal  to  the  Joint  STARS  simulation  and  is  much  more  drastic.  VSTARS 
must  be  capable  of  functioning  an5where  needed,  to  include  on  board  an  aircraft  during  the  conduct  of  a 
mission.  This  requires  that  the  DIS  network  interface  unit  (NIU)  for  VSTARS  exist  in  two  parts,  a 
ground  NIU  (GNIU)  and  an  aircraft  NIU  (AMU).  The  GNIU  remains  at  a  fixed  location  and  receives 
ESPDUs  firom  the  DIS  network.  It  then  strips  and  modifies  the  ESPDU  down  to  192  bits  of  essential 
information  and  sends  it  to  the  ANIU.  The  AMU  performs  the  dead  reckoning  function  and  updates 
the  data  bases  used  to  generate  the  virtual  radar  images.  The  AMU  resides  in  the  same  computer 
hosting  VSTARS  and  may  be  found  in  a  variety  of  locations  such  as  a  laboratory,  on  board  the  aircraft, 
or  at  a  training  site.  This  paper  describes  the  modifications  to  the  ESPDU  and  some  of  the  reasons  for 
the  modifications.  This  procedure  can  be  tailored  for  any  sensor  system  that  is  not  easily  connected  to  a 
DIS  network. 
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INTRODUCTION 


The  End-to-End  Test  (ETE)  of  the  Joint  Advanced  Distributed  Simulation  (JADS)  Joint  Test  Force 
(JTF)  will  evaluate  die  utihty  of  using  advanced  distributed  simulation  (ADS)  to  complement  the 
developmental  and  operational  test  and  evaluation  of  a  Command,  Control,  Communications, 
Computers,  and  Intelligence  (C4I)  system.  The  Joint  STARS  combination  of  E-8C  aircraft  and  Ground 
Station  was  chosen  as  a  representative  C4I  system  on  which  to  introduce  ADS  as  a  methodology  in 
both  DT&E  and  OT&E  settings. 

Joint  STARS  provides  commanders  access  to  near  real-time  radar  imagery  data  in  support  of  targeting 
decisions.  The  E-8C  aircraft  radar  looks  deep  into  hostile  areas  to  detect,  locate,  classify,  and  track 
thousands  of  potential  targets.  This  radar  operates  in  two  basic  radar  modes:  moving  target  indicator 
(MTI)  and  synthetic  aperture  radar  (SAR).  MTI  is  capable  of  displa3dng  the  position  of  moving 
ground  vehicles.  SAR  can  provide  images  of  both  moving  and  nonmoving  targets  and  of  terrain  and 
cultural  features. 

Previous  C4I  system  testing  has  exhibited  shortfalls  in  providing  adequate  numbers  of  forces,  fiiendly  or 
enemy,  to  realistically  portray  an  expected  operational  environment.  ADS  can  generate  a  robust  test 
environment  by  providing  a  more  representative  number  of  threats,  plus  the  complementary  suite  of 
other  C4I  and  the  weapons  systems  that  interact  with  a  C4I  system.  Through  a  seamless  mixing  of  Hve 
and  virtual  targets,  the  ETE  will  add  thousands  of  additional  entities  to  the  few  hundred  available  in 
peacetime  battlefield  exercises,  and  will  better  rephcate  a  developed  theater. 

The  ETE  is  a  four-phase  test.  Phases  1  and  2  occur  in  a  laboratory  environment,  suitable  for  exploring 
DT&E  and  early  OT&E  applications.  Phase  3  checks  compatibihty  of  tire  ADS  environment  with  the 
actual  Joint  STARS  equipment.  Phase  4  is  an  ADS-enhanced  hve  open-air  test  linking  a  flying  E-8C 
aircraft  to  actual  ground  station  receivers,  intelUgence  systems,  fire  control,  and  virtual  shooters.  A 
schematic  of  Phase  4  is  shown  below. 
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T est  Control 


Figure  1«  ETE  Architecture 


RF  LIMITATIONS 

In  a  typical  DIS  network,  all  simulation  components  are  linked  over  local  or  wide-area  ground-based 
networks.  The  ETE  wUl  link  such  ground  networks,  but  also  must  include  a  flying  aircraft  receiving 
update  information  firom  a  DIS  network.  This  presents  special  challenges  due  to  constraints  on  available 
radio  frequency  (RF)  bandwidth  between  a  ground  transmitter  and  a  receiver  on  board  the  aircraft. 
Current  RF  bandwidth  available  for  the  ETE  is  limited  to  around  19.2  kbps. 

The  current  ETE  network  interfaces  support  a  maximum  of  100  ESPDUs  per  second.  The  DIS  version 
2.0.4  ESPDU  contains  1152  bits  of  information  (minimum),  requiring  a  transmission  rate  of  (1 152)(100) 
=  115  kbps,  much  greater  than  the  available  bandwidth.  Additionally,  the  E-8C  aircraft  provides  an 
ESPDU  denoting  its  existence  and  flight  information  on  a  1  Hz  update.  This  bandwidth  discrepancy 
drove  development  of  the  modified  ESPDU  and  network  interface  units  used  in  the  ETE. 

ETE  ARCHITECTURE 

The  VSTARS  architecture  receives  ESPDUs  from  a  DIS  network  through  a  ground  network  interface 
unit  (GNIU),  and  transmits  a  modified  PDU  via  an  RF  datalink  to  the  corresponding  air  network 
interface  unit  (AMU)  aboard  the  flying  aircraft. 
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Joint  STARS  Aircraft 


Figure  2;  VSTARS  Network  Interface  Units 


NETWORK  INTERFACE  UNITS 

The  Ground  Network  Interfece  Unit  first  determines  if  arriving  PDUs  are  Entity  State  PDUs.  It  then 
filters  out  those  ESPDUs  that  are  not  within  the  E-8C  simulation’s  area  of  interest.  The  remaining 
ESPDUs  are  stripped  to  a  data  packet  containing  the  minimum  information  required  to  drive  the  MTI 
and  SAR  simulations  in  VSTARS.  (This  process  is  described  later  in  this  paper.)  The  GNIU  converts 
location  coordinates  from  DIS  Earth-Centered-Earth-Fked  to  the  Topocentric  Coordinate  System 
used  on-board  the  E-8C  and  in  the  RPSI.  This  conversion  is  done  on  the  ground  to  save  processing 
cycles  onboard  the  aircraft.  The  GNIU  then  constracts  an  RF  link  message  and  transmits  a  stripped 
and  modified  data  packet  containing  ground  target  information  to  the  receiving  ANIU. 

The  Air  Network  Interface  Unit  receives  the  incoming  data  packet  and  places  the  information  in  its 
target  database.  The  ANIU  performs  dead  reckoiting  on  these  targets,  and  updates  the  database  based 
on  its  dead  reckoning  estimations  and  incoming  target  information.  Dead  reckoning  is  done  on-board 
the  aircraft  to  save  RF  transmission  bandwidth  fi’om  the  GNIU.  On  request  firom  the  RPSI,  the  ANIU 
searches  its  database  for  those  targets  located  in  the  appropriate  ground  location  and  provides  such 
data  to  the  RPSI  SAR  or  MTI  simulation. 

Conversely,  VSTARS  provides  to  the  ANIU  data  regarding  the  existence  and  location  of  the  E-8C 
aircraft.  The  ANIU  then  composes  and  transmits  a  location  data  packet  back  to  the  GNIU  denoting 
this  information.  The  GNIU  reforms  the  E-8C  data  into  a  DIS  2.0.4  ESPDU  and  broadcasts  it  to  the 
DIS  network. 

ESPDU  UPDATE  MODIFICATIONS 

DIS  simulations  normally  send  out  ESPDUs  on  both  a  dead-reckoning  update  and  a  heartbeat  basis. 
Dead-reckoning  updates  are  sent  whenever  an  entity  location  maintained  in  the  simulation’s  internal 
location  database  exceeds  by  a  given  error  parameter  the  locations  maintained  in  some  external  DIS 
simulation  database.  Heartbeat  ESPDUs  are  broadcast  on  a  periodic  basis  (once  every  five  seconds  is 
recommended  by  the  DIS  standard)  to  permit  simulations  just  entering  the  DIS  network  to  initialize  then- 
databases,  and  also  for  those  visual  engines  that  require  periodic  updates. 
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The  ETE  simulation  driver  broadcasts  dead-reckoning  ESPDUs  using  the  locational  error  parameters  of 
the  E-8C  radar  (i.e.,  radar  CEP).  This  parameter  can  be  decreased  in  the  simulation  software  as 
necessary  to  account  for  latency  in  the  ETE  network.  For  example,  assume  the  E-8C  locational 
parameter  error  is  50  meters.  A  vehicle  traveling  at  5  meters  /  second  can  exceed  the  locational  error  in 
5  seconds,  necessitating  an  ESPDU  update  within  5  seconds.  However,  if  network  latency  is  1  second, 
the  dead-reckoning  update  must  be  shortened  by  at  least  1  second  (by  adjustment  of  locational  error 
parameter)  for  locational  accuracy  to  remain  within  the  aircraft  radar  CEP.  Reducing  the  E-8C 
locational  error  parameter  setting  to  30  meters  would  require  an  ESPDU  update  in  3  seconds.  On  top 
of  the  1  second  latency,  the  updated  ESPDU  would  arrive  at  a  distant  simulation  in  4  seconds,  which  in 
effect  is  less  than  the  radar  CEP. 

Between  dead-reckoning  updates,  the  ETE  simulation  driver  broadcasts  heartbeat  ESPDU  updates. 
Since  the  ETE  network  architecture  and  simulation  participants  are  fixed  prior  to  exercise  initiation,  no 
new  players  will  join  once  the  exercise  begins;  therefore,  the  newly  entering  simulation  heartbeat 
requirement  is  eliminated.  Also,  none  of  the  ETE  visual  engines  require  periodic  updates.  Were  it  not 
for  the  small  chance  of  a  non-mover  being  accidentally  lost  fi’om  the  VSTARS  database,  this  heartbeat 
could  be  eliminated.  For  VSTARS,  the  heartbeat  is  set  initially  and  arbitrarily  at  a  10-minute  update 
interval. 

ETE  ESPDUs  arriving  at  VSTARS  are  maintained  in  a  target  database.  Targets  that  are  moving,  or 
those  stopping  or  starting,  are  updated  as  described  above.  Stationary  targets  are  initialized  in  the 
database  at  exercise  initiation.  Once  entered  in  the  ANRJ  target  database,  targets  are  not  routinely 
removed.  Those  targets  that  become  battle-damaged  or  destroyed  remain  as  burning  hulks  to  be 
imaged  by  the  E-8C  SAR  radar. 

ESPDU  DATA  MODIFICATIONS 

The  VSTARS  simulation  driver  need  not  provide  the  extensive  target  data  available  fi'om  the  standard 
DIS  ESPDU  —  information  such  as  color,  national  origin,  model,  and  so  on  is  simply  not  visible  to  the 
E-8C  radar  sensor.  This  allows  the  ETE  to  strip  such  information  firom  the  ESPDU,  and  results  in  a 
smaller  data  packet  that  must  be  transmitted  to  the  flying  aircraft. 
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Field  Size 

ETE  Modified  ESPDU 

PDU  Header 

Time  Stamp 

32 

Entity  ID 

Entity 

16 

Entity  Type 

Category 

8 

Subcategory 

8 

Specific 

8 

Extra 

8 

Entity  Linear 
Velocity 

X-Component 

16 

Y-Component 

16 

Z-Component 

16 

Entity 

Location 

X-Component 

16 

Y-Component 

16 

Z-Component 

16 

Entity  Orientation 

Psi 

16 

PDU  Size 

192  bits 

Chart  1.  ETE  Modified  ESPDU 


Field  Size 
E^8C  ESPDU 

Header 

Time  stamp 

32 

Er8C  Location 

X-Component 

32 

Y-Component 

32 

Z-Component 

32 

B-8C  Velocity 

X-Component 

32 

Y-Component 

32 

Z-Component 

32 

TBD 

reserved 

32 

Total  PDU  Size 

256 

Chart  2:  ETE  E-8C  ESPDU  composition 


•  The  VSTARS  time  stamp  records  the 
ESPDU  creation  time  for  up  to  8  exercise 
hours,  compared  with  the  DIS  protocol  of 
restarting  every  hour.  This  is  required  by  a 
normal  8  hour  Joint  STARS  mission  length. 

•  Entity  Type  contains  the  minimum 
information  required  for  an  overhead  radar 
sensor  as  described  above. 

•  Location  data  has  been  converted  from 

Earth-Centered-Earth-Fixed  to 

Topocentric  Coordinate  System  and 
reduced  to  16-bit  accuracy,  sufficient  to 
remain  within  the  error  requirements  of  the 
E-8C  radar. 

•  Likewise,  velocity  data  has  been  reduced  to 
16-bit  accuracy. 

•  Orientation  is  restricted  to  that  visible  to  the 
E-8C  radar  in  the  radar  slant  plane. 

Total  Modified  ESPDU  size  is  192  bits, 

compared  with  1152  +  128n  bits  in  the  DIS 

2.0.4  ESPDU. 


The  E-8C  aircraft  transmits  a  1  Hz  state 
message  from  the  ANIU  to  the  GNIU  denoting 
its  existence,  location,  and  velocity.  The  GNIU 
translates  this  into  an  E-8C  ESPDU  and 
broadcasts  over  the  DIS  network.  This 
information  permits  the  aircraft  to  be  visible  to 
other  players  in  the  DIS  environment. 
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This  results  in  the  following  transmission  bandwidth  requirements. 


entities  /  sec 

#  entities 

#bits 

kbps 

Uplink  Messages, 
GNIUtoANIU 

Max  sustained  rate 

100 

19,200 

19.2 

10  min  heartbeat  rate 

33 

20,000 

6,400 

6.4 

Downlink  Messages, 

ANIU  to  GNIU 

Joint  STARS  state 
message  @  Ihz 

1 

1 

256 

0.26 

Total  RF  link  bandwidth  requirements 

25.86 

Charts:  Transmission  Bandwidth 


Available  ETE  RE  bandwidth  to  the  ETE  is  19.2  kbps.  Using  a  nominal  compression  ratio  of  1.4:1,  the 
required  bandwidth  is  reduced  to  14  kbps,  which  fits  within  capacity. 

CONCLUSIONS 

For  an  overhead  stand-off  system  such  as  MTI  or  SAR  radar,  the  DIS  ESPDU  can  be  drastically 
reduced  in  size  and  still  provide  the  resolution  and  fidehty  necessary  to  provide  accurate  sensor 
information  for  training  exercises  or  developmental  and  operational  testing  and  evaluation.  Such  a 
procedure  can  be  apphed  to  any  sensor  that  cannot  ‘see’  all  the  detailed  information  available  in  the  DIS 
ESPDU.  The  combination  of  ESPDU  stripping  and  update  rate  modifications  allows  a  flying  aircraft  to 
participate  in  a  realistic  DIS  exercise.  These  procedures  can  be  used  to  bring  together  various  real 
combat  equipment  linked  over  radio  nets  into  a  DIS  simulation  without  the  restrictions  posed  by  limited 
RF  bandwidths. 
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1.  Introduction 


This  document  reports  on  the  results  of  work  conducted  by  Northrop  Grumman  to  demonstrate  the 
utility  of  existing  Advanced  Distributed  Simulation  (ADS)  for  use  during  Multi  Service  Operational  Test 
and  Evaluation  (MOT&E).  This  project  was  sponsored  by  the  Joint  Advanced  Distributed  Simulation 
(JADS)  Joint  Test  Force  (JTF).  This  white  paper  documents  the  Scientific  and  Technical 
accomplishments  through  Phase  lb  of  the  program.  This  phase  provided  for  a  laboratory  system 
development,  demonstration,  and  preliminary  performance  assessment  of  a  Radar  Processor  Simulation 
and  Integrator  (RPSI),  for  the  purpose  of  simulating  the  Joint  Surveillance  Target  and  Attack  Radar 
System  (JSTARS)  Radar  products,  with  coimections  via  the  Distributed  Interactive  Simulation  (DIS) 
network  to  the  JADS  End  to  End  (ETE)  simulated  environment  (SE). 

ADS  is  defined  as  "any  application  or  architecture  which  employs  the  characteristics  of  distribution  and 
networking  in  a  way  which  permits  a  number  of  nodes,  entities,  or  devices  (at  least  two)  to  interact  with 
each  other  for  some  common  or  shared  pxupose  related  to  Test  and  Evaluation  (T&E),  thus  allowing  the 
creation  of  realistic,  complex,  virtual  worlds  for  the  simulation  of  highly  interactive  activities.”  The  three 
possible  types  of  players  (also  known  in  the  DIS  community  as  participants  or  entities)  are  listed  below: 

•  Live:  real  systems,  real  people,  and  real  environments,  operational  platforms  and  test  and 
evaluation  systems. 

•  Virtual:  simulators  EDDL/HWIL  (Human  in  the  Loop/  Hardware  in  the  Loop) 

•  Constructive:  models,  digital  simulations,  computer  generated  forces,  systems  and  environments 
and  war  games. 

The  term  ADS  has  been  developed  to  include  network  implementations  which  do  not  completely 
conform  to  the  IEEE  1278  standards,  but  otherwise  adhere  to  the  basic  tenets  of  DIS  as  described 
above.  The  term  ADS  includes  DIS  as  a  subset  and  is  intended  to  support  a  mixture  of  virtual,  live,  and 
constmctive  entities.  Northrop  Grumman  currently  is  contracted  by  the  Joint  Advanced  Distributed 
Simulation  Joint  Test  Force  (JADS  JTF)  to  develop  a  Joint  STARS  RPSI  which  interfaces  to  the  DIS 
network.  The  DIS  network  is  a  media  for  participation  in  ADS  activities. 

2.  Summary  of  the  Project 

The  objective  of  this  effort  was  to  develop  a  system  to  enhance  the  existing  JADS.  JADS  is  being 
developed  to  prove  the  ADS  concept  by  means  of  an  ETE  test  scenario,  whereby  a  battlefield 
environment  is  simulated  including  multiple  moving  and  non  moving  targets,  target  detection,  assignment, 
reporting,  and  target  engagement.  The  Joint  STARS  E-8C  platform  is  to  be  a  major  participant  and  will 
utilize  the  Joint  STARS  Radar  and  the  RPSI  to  support  the  ETE  Test  that  will  be  conducted  by  the 
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JADS  JTF.  The  integrated  E-8C  Radar  and  simulation  will  provide  simulated  Radar  reports  integrated 
with  Uve  Radar  reports  when  operating  within  the  JADS  JTF  ETE  Test  environment. 

Northrop  Grumman  was  contracted  to  develop  and  implement  a  laboratory  version  of  the  RPSI  and  to 
provide  the  connections  via  the  DIS  to  the  JADS  ETE  simulated  environment.  Phase  la  consisted  of  an 
architecture  and  design  study  to  determine  the  feasibility  of  the  product.  (See  References  2,  3  and  4). 
The  scope  of  the  Phase  lb  effort,  which  was  based  on  that  work  included  the  design  and  development 
of  VSTARS  software  compatible  with  JADS  and  the  DIS  network  and  standards.  This  software  was 
integrated  in  commercial  hardware  with  ancillary  Radar  control  software  tasks,  i.e.,  those  which 
normally  are  provided  by  the  actual  E-8C  Prime  Mission  Equipment  (PME).  Some  of  the  Joint  STARS 
software  was  modified  for  use  with  the  RPSI.  VSTARS  is  the  laboratory  version  of  the  RPSI,  and  is  a 
simulation  environment  representing  the  generation  and  dissemination  of  Radar  products  by  the  Radar 
Subsystem  of  the  E-8C  aircraft. 

Northrop  Grumman  has  developed  VSTARS  consisting  of  a  Distributed  Interactive  Simulation  Interface 
Unit  (DISNIU),  a  Radar  Processor  Simulator  and  Integrator  (RPSI),  and  a  Datalink  Databus  Interface 
Unit,  to  conclude  Phase  lb.  The  RPSI  is  stimulated  by  virtual  target  data  which  are  received  in  the  form 
of  Entity  State  Protocol  Data  Units  (ES  PDU)  fi-om  the  DIS  network.  These  PDUs  which  are  generated 
by  a  scenario  generator,  are  data  which  describe  the  position,  motion,  orientation  and  identity  of  the 
virtual  targets.  The  RPSI  receives  Radar  Service  Requests  (RSR)  from  either  an  operator  work  station 
(OWS)  or  a  Ground  Station  Module  replica  (GSMR)  and  provides  Radar  Target  Reports  (MTI  and 
SAR)  to  the  OWS  and  to  the  GSMR.  In  VSTARS,  RPSI  communication  with  the  GSMR  is  provided 
by  software  tasks  and  a  telephone  link  which  simulate  the  Surveillance  Control  Data  Link  (SCDL)  of 
the  E-8C.  The  SAR  simulation  was  developed  by  Lockheed  Martin  and  was  integrated  into  the  RPSI 
by  Northrop  Grumman. 

In  addition,  a  preliminary  performance  assessment  of  VSTARS  was  successfully  conducted,  to 
ascertain  that  VSTARS  satisfied  the  requirements  and  was  ready  for  the  planned  follow-on  phases  of 
the  JADS  ETE  program.  This  included  characterization  of  the  DIS  interface  by  measuring  the  rate  at 
which  the  entity  state  PDUs  can  be  received. 

The  planned  follow  on  JADS’  phases  are  intended  to  verify  and  validate  the  results  of  this  work,  to 
migrate  the  RPSI  to  the  Primary  Mission  Equipment  (PME)  of  the  E-8C  aircraft,  to  conduct  operational 
tests  of  the  RPSI  in  a  flying  E-8C  aircraft,  and  to  support  JADS  ETE  Team  tests. 
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3.  Task  Description 


The  scope  of  this  task  included  the  design,  development  and  test  of  software  compatible  with  the 
existing  JADS  SE  for  the  purpose  of  simulating  the  Joint  STARS  Radar  effects  on  virtual  targets. 

The  tasks  which  have  been  conducted  during  Phase  lb,  were  to  develop  a  DIS  Network  Interface  Unit 
(DISNIU),  a  RPSI  and  a  Databus  Datalink  Interface  Unit  to  satisfy  the  following  requirements: 

•  Develop  a  DISNIU  to  receive,  process  and  transmit  DIS  virtual  target  ES  PDUs  to  the  RPSI,  and 
to  transmit  aircraft  ES  PDUs  to  the  DIS  network.  Develop  the  DISNIU  such  that  it  can  later  be 
implemented  in  the  E-8C  PME. 

•  Develop  a  Joint  STARS  simulation  consisting  of  a  RPSI,  which  simulates  the  E-8C  Joint  STARS 
Radar  Subsystem  products  and  provides  reports  to  OWS,  and  to  remote  ground  stations,  the 
latter  via  a  specialized  connection  to  a  WAN.  The  RPSI  architecture  is  in  accordance  with 
Architectural  candidate  2,  as  described  in  reference  2,  and  satisfies  the  following  requirements: 

•  Provides  for  integration  of  simulated  and  live  radar  data  when  operating  within  the  JADS  Joint 
Test  Force  ETE  environment. 

•  Simulates  the  generation  of  MTI,  SAR  and  Fixed  Target  Indicator  (FTI)  reports. 

•  Operates  in  three  modes:  mixed,  virtual  and  real. 

•  Implements  dead  reckoning  algorithms  to  minimize  DIS  network  virtual  target  update 
requirements 

•  Provides  real  or  simulated  aircraft  inertial  data  information  to  the  MTI  and  SAR  simulations. 

•  Is  implemented  within  a  commercial  representation  (ALPHA  600  Workstations)  of  the  Joint 
STARS  E-8C  PME,  in  the  Northrop  Grumman  ITF. 

•  Develop  a  Databus  Datalink  Interface  Unit  to  enable  the  transmission  SCDL  traffic  (MTI  and  SAR 
reports)  to  an  Army  GSM  or  CGS  or  replica  of  such;  and  to  enable  reception  of  Radar  service 
requests  from  the  ground  station. 
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4.  Technical  Approach 


The  following  paragraphs  describe  the  work  that  was  performed,  the  architecture  selected,  and  the 
design  of  the  RPSI.  It  also  describes  the  associated  interfaces  between  the  JADS  JTF  facilities  and  the 
laboratory  version  of  the  RPSI,  VSTARS.  The  RPSI  software  tasks  are  integrated  with  actual  Radar 
subsystem  software.  Since  the  approach  was  to  develop  the  RPSI  to  execute  initially  in  the  NG 
laboratory  in  ALPHA  600  work  stations,  and  then  in  later  phases  to  execute  in  the  E-8C  PME,  existing 
Joint  STARS  subsystem  software  modules  were  integrated  with  the  RPSI  in  the  ALPHA  600 
computers.  These  modules  were  augmented  with  additional  software  tasks,  which  were  designed  to 
intercept  normal  post  processing  outputs  in  order  to  insert  simulated  target  information,  and  to  provide 
the  interfaces  with  the  DIS  network  and  the  SCDL  emulation.  This  provides  for  MTI  and  FTI  reporting 
of  the  virtual  targets  and  virtual  SAR.  During  the  planned  follow  on  phases,  only  the  newly  developed 
and  modified  software  will  need  to  be  migrated  to  the  JSTARS  PME,  since  the  other  Radar  functions 
will  be  provided  by  existing,  unmodified  portions  of  the  Radar  subsystem. 

4.1  RPSI  Architecture  and  Design 

The  RPSI  was  developed  to  be  in  accordance  with  Architectural  candidate  2,  as  described  in 
Reference  2.  Whereas  the  RPSI  currently  is  implemented  in  commercial  hardware  in  the  laboratory,  it 
was  designed  to  enable  the  functional  partitioning  shown  in  Figure  4.1  when  it  is  migrated  to  the  E-8C 
PME.  This  figure  shows  the  planned  partitioning  of  the  RPSI  software  to  execute  primarily  in  the 
“spare”  general  purpose  computer  (GPC-3),  and  in  one  of  the  Advanced  Technology  Workstations 
(ATWS).  The  following  paragraphs  describe  VSTARS,  the  laboratory  version  of  the  Radar  simulation. 
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Shaded  areas  identify 
RPSI  functions 


Figure  4  RPSI  Functions  to  be  Installed  in  JSTARS  PME 


4.2  VSTARS/RPSI  Relationship  to  JSTARS 

VSTARS  was  developed  from  a  combination  of  existing  Joint  STARS  Radar  software  and  new 
software,  and  executes  in  two  DEC  ALPHA  600  workstations.  It  should  be  emphasized  that  the  RPSI 
does  not  operate  on  its  own  but  is  integrated  with  actual  Radar  subsystem  software. 

VSTARS  operates  as  follows: 

Virtual  target  ES  PDUs  are  received  via  a  LAN  and  a  T1  communication  service,  from  the  remote 
scenario  generator,  JANUS,  via  the  DIS  network.  VSTARS  DISNIU  software  receives  and 
processes  the  PDUs,  placing  the  virtual  target  data  in  global  memory.  The  RPSI  software  accesses  this 
data,  simulates  MTI  and  SAR  processing  affects  and  generates  Radar  Reports.  These  reports  are 
provided  via  a  LAN,  for  display  at  the  OWS,  or  for  transmission  via  a  SCDL  emulation  to  a  remote 
GSMR,  via  a  WAN  (T1  communications  service).  The  RPSI  also  receives  Radar  Service  Requests 
from  the  GSMR  via  this  WAN,  and  these  are  executed  by  VSTARS. 

ITie  combination  of  existing  or  modified  Joint  STARS  Radar  software  and  the  newly  developed  RPSI 
software  modules,  which  were  migrated  to  the  ALPHA  600  computers  to  perform  these  tasks  are 
depicted  in  the  following  figures  as  unshaded  and  shaded  blocks  respectively.  The  “unshaded”  fimctions 
provide  for  the  auxiUaiy  and  parameter  messages  and  controls,  and  reporting  processes  which  normally 
are  provided  by  the  actual  Radar  Subsystem.  Some  of  the  “shaded”  fimctions  provide  for  the  DISNIU 
fimctions,  which  receive  and  process  the  ES  PDUs  (bit  stripping,  coordinate  conversion  and  dead 
reckoning  which  are  described  below).  Other  shaded  fimctions  provide  for  the  SCDL  emulation. 
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Additional  shaded  functions  provide  the  simulation  of  MTI  and  SAR/FTI  processing  and  product 
generation,  and  provide  the  interfaces  between  the  RPSI  and  the  Radar  software  tasks.  Although  the 
SATCOM  Subsystem  block  is  shown  as  shaded,  the  SATCOM  processor  software  wiU  be  modified  in 
the  planned  follow-on  phases,  to  provide  the  RF  link  between  the  RPSI  and  the  DIS  network. 

The  result  is  a  simulation  of  the  Joint  STARS  Radar  products  “in  a  box”  (the  ALPHA  600  commercial 
computers),  providing  all  of  the  JSTARS  databases,  post  processing,  operator  displays  and  controls, 
and  Operation  and  Control  (O  &  C)  Subsystem  functions  (e.g.,  target  tracking  and  reporting)  which  are 
necessary  for  a  realistic  simulation  of  the  Joint  STARS  Radar  products  generation  and  display  and  O  & 
C  Subsystem  functions  and  interfaces. 

Figure  4.2  provides  a  block  diagram  of  the  MTI  processing  mode  and  is  an  example  of  the  relationship 
between  the  major  Radar  functions  of  the  RPSI  and  of  the  Joint  STARS  RADAR  software  which 
comprise  VSTARS.  Figure  4.3  is  the  corresponding  block  diagram  for  the  SAR  processing  mode  of  the 
RPSI.  The  operation  of  the  RPSI  Interfaces  and  the  MTI  and  SAR  simulation  software  tasks  are 
described  below  in  Paragraphs  4.2.3  and  4.2.4.  But,  first  the  RPSI  laboratory  hardware  configuration 
and  functional  partitioning  are  described. 


Figure  4L  MTI  Mode  Shows  Relationship  &  Dependency  of  the  RPSI  to  the  JSTARS 

RADAR 
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Figure  41  SAR  Mode  Block  Diagram  Shows  Relationship  &  Dependency  of  RPSI  TO 

JSTARS  RADAR 

4.2.1  Laboratory  Hardware  Configuration  and  Functional  Partitioning 

Figure  4.4  shows  the  laboratory  configuration  of  the  RPSI,  known  as  VSTARS.  VSTARS  provides  the 
software  fimctions  of  the  Joint  STARS  System  Management  and  Control  (SM&C)  computer,  the 
Radar  Data  Processor  (RDP,  known  as  GPCl),  the  Central  Data  Computer  (CDP,  known  as  GPC2) 
and  the  Advanced  Technology  Workstation  (ATWS),  by  utilizing  the  actual  Radar  System  software 
modules.  As  noted  above,  some  of  these  were  modified  and  additional  software  modules  were 
developed  for  VSTARS. 

At  present  aU  of  VSTARS  is  configured  to  run  on  dual  ALPHA  600  workstations  with  software 
fimctions  partitioned  as  shown  in  Figure  4.4,  or  on  a  single  ALPHA  600.  SAR  generation  occurs  more 
rapidly  when  two  ALPHA  600s  are  utilized.  Each  ALPHA  600  is  equipped  with  a  single  333-Mhz 
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CPU.  One  is  equipped  with  512  MBytes  of  RAM,  the  other  with  1  GByte  of  RAM  for  SAR 
processing.  The  operating  system  is  DEC  OpenVMS  Version  7.0.  The  VSTARS  software  baseline  is  a 
variant  of  Joint  STARS  software  Build  108B. 

One  of  the  workstations  (JADSOl)  interfaces  via  an  Ethernet  LAN  with  an  SGI  workstation,  which  is 
used  for  logging  or  playback  of  the  DIS  PDUs.  The  SGI  and  the  ALPHA  600  workstations  connect  via 
the  LAN  to  a  T-1  communication  service  network,  which  provides  the  interface  to  the  DIS  network. 
The  interface  which  emulates  the  SCDL  to  the  GSMR  also  is  via  a  T1  communications  service. 

Both  the  DEC  ALPHA  600  operator  workstation  keyboards  and  displays  in  the  Northrop  Grumman 
“JADS  Laboratory”,  and  the  E-8C  PME  operator  work  stations  (OWS)  in  the  Northrop  Grumman 
OCTL  laboratory  have  been  utilized  with  the  RPSI  executing  in  the  ALPHA  600s.  Since  the  latter 
OWS  are  the  same  as  those  utilized  in  the  E-8C  aircraft,  they  are  utilized  for  realistic  demonstrations  of 
VSTARS  and  are  recommended  for  realism  when  operator  performance  tests  and  assessment  of 
VSTARS  are  to  be  conducted. 


JADSOl  (ALPHA  600)  JADS02  (ALPHA  600) 


Figure  41  VSTARS,  the  Laboratory  Configuration  of  the  RPSI 
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4.2.2  DIS  Interface  Design  and  Operation 


The  DIS  Interface  provides  for  the  receipt  of  ES  PDUs  from  any  DIS  compliant  PDU  generator,  (see 
Reference  6).  For  this  project,  PDUs  were  generated  by  JANUS  and  delivered  via  the  T1  service  and 
a  Northrop  Grumman  Ethernet  LAN  directly  to  the  DISNIU  software  tasks,  or  replayed  from  the  SGI 
logger,  which  also  records  and  can  replay  the  PDUs  that  are  received  from  JANUS.  In  order  to 
provide  for  the  eventual  migration  of  the  RPSI  to  an  E-8C  aircraft,  the  DISNIU  software  was  designed 
with  two  parts:  a  Ground  DISNIU  (GNDNIU)  and  an  Air  DISNIU  (AIRNIU).  In  VSTARS,  the 
laboratory  version  of  the  JSTARS  Radar  emulation,  both  DISNIUs  execute  in  an  ALPHA  600.  In  the 
planned  aircraft  version,  the  AIRNIU  will  be  installed  in  the  aircraft  PME.  The  GNDNIU  will  remain  in 
the  laboratory  ALPHA  600  which  will  be  interfaced  with  a  ground  site  SATCOM  system  to  provide  an 
RF  link  to  the  aircraft  (see  section  4.2.7),  and  thence  to  the  AIRNIU. 

The  GNDNIU  software  module  (see  JADSOl  in  Figure  4.4)  interfaces  with  the  Northrop  Grumman 
Ethernet  LAN  which  in  turn  interfaces  with  the  DIS  network  via  the  T1  communication  service. 
Although  there  are  provisions  for  more  than  1152  data  bits  in  the  standard  DIS  compliant  PDU,  this 
data  was  reduced  to  192  bits  in  order  to  minimize  the  bandwidth  requirements  for  passage  of  the  target 
data  to  the  aircraft.  To  achieve  this  compression,  the  PDUs  received  by  the  GNDNIU  are  stripped  of 
the  unnecessary  data.  The  position  and  velocity  data  of  the  ESPDU  are  coordinate  converted  from  an 
earth  centered  (geodetic)  coordinate  system  to  the  Topocentric  Coordinate  System  (TCS),  which  is 
employed  by  the  JSTARS.  The  conversion  algorithm  utilizes  the  current  Joint  STARS  mission  center 
and  supports  the  512  by  512  km  JSTARS  mission  area.  The  virtual  target  position  is  quantized  to  16 
meters  and  velocity  is  quantized  to  0.0061  meters/second.  The  resultant  192  virtual  target  data  bits  (see 
Table  4. 1)  are  forwarded  to  the  AIRNIU. 

This  virtual  target  data  is  received  from  the  GNDNIU  by  the  AIRNIU  and  stored  in  global  memory. 
Periodically,  (currently  once  per  second)  tire  target  position  (of  moving  targets)  is  updated  by  dead 
reckoning.  This  data  is  available  for  ftirther  processing  in  the  MTI  or  SAR  processing  mode,  as 
described  in  the  following  sections. 

The  AIRNIU  also  has  been  designed  to  periodically  (currently  once  per  second)  acquire  and  send  an 
aircraft  PDU  to  the  GNDNIU,  which  in  turn  will  dehver  the  aircraft  PDU  to  the  DIS  network.  Table  4.2 
shows  the  PDU  fields  for  this  JSTARS  downlink  PDU.  Altiiough  the  RPSI  simulates  the  generation  and 
sending  of  aircraft  PDUs,  the  software  is  designed  so  that  the  default  mode  for  this  fimction  is  “OFF”,  in 
order  to  eliminate  any  interference  during  the  receipt  of  ES  PDUs  from  the  DIS  networic  during 
laboratory  tests. 
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Table  41  Uplink  Entity  State  PDU  for  JADS  RPSI 


FORMAT 

BITS  IN  FIELD 

INFORMATION 

Unsigned  Integer 

32 

Local  Target  ID 

Unsigned  Short 

16 

TCS  X  Cell 

Unsigned  Short 

16 

4K  cell  and  16m  cell 
in  Y  axis 

TCSYCell 

Unsigned  short 

16 

4K  cell  and  16  m  cell 
inXaxis 

TCS  Z  Cell 

Unsigned  Short 

16 

(16383)m  lsb=0.5m 

Velocity  X 

Short 

16 

(200)m/s 

lsb=6. 1035ram/sec 

Velocity  Y 

Short 

16 

(200)m/s 

lsb=6.1035mm/sec 

Velocity  Z 

Short 

16 

(200)m/s 

lsb=6. 1 035mm/sec 

Entity  Category 

char 

8 

enumeration 

Entity  Sub  Category 

char 

8 

enumeration 

Entity  Specific 

char 

8 

enumeration 

Appearance 

char 

8 

8  bit  extraction  from 
32  bits 

Orientation  Angle 

short 

16 

(180)deg.  extraction 
from  32  bits 

TOTAL  BITS 

192 

Table  42  Downlink  Entity  State  PDU  for  JADS  RPSI 


FIELD  DATA 

FORMAT 

BITS  IN  FIELD 

Time  Stamp 

Unsigned  Integer 

32 

TCS  Location  X 

Float 

32 

TCS  Location  Y 

Float 

32 

TCS  Location  Z 

Float 

32 

TCS  Velocity  X 

Float 

32 

TCS  Velocity  Y 

Float 

32 

TCS  Velocity  Z 

Float 

32 

TBD 

Integer 

32 

TOTAL  BITS 

256 
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4.2.3  MTI  Processing  Simulation 

The  MTI  simulation,  which  was  designed  for  the  laboratory  version  of  the  RPSI,  is  illustrated  in  Figure 
4.5  which  shows  the  major  software  tasks  and  message  flow. 


i 


Radar  Service  Request 


IPK5SRM 

I 


Figure  ^  RPSI  MTI  Processing  Simulation  (Laboratory  Mode) 

RCUSIM  and  PSPSIM  are  software  tasks  which  were  developed  for  VSTARS,  to  be  used  in  the 
laboratory  version  of  the  RPSI.  These  software  modules  provide  for  those  inputs  which  normally  are 
provided  by  the  actual  Radar  Control  Unit  (RCU),  and  the  Programmable  Signal  Processors  (PSP)  of 
the  Radar  system.  These  operate  in  conjunction  with  new  RPSI  software  tasks. 

MTISIM  and  the  DISNIU  software  tasks  and  the  modified  PK2MCP,  PK4RPT  and  PK5SRM 
software  will  form  part  of  the  RPSI  software  which  will  be  migrated  to  the  E-8C  PME  during  follow  on 
phases.  PSPSIM  and  RCUSIM  will  not  be  required  in  the  aircraft,  since  the  functions  which  are 
provided  by  these  software  tasks  in  the  laboratory  will  be  provided  in  the  aircraft  by  the  Programmable 
Signal  Processors  (PSP)  and  the  Radar  Control  Unit  (RCU)  of  the  JSTARS  Radar  subsystem. 
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The  new  RPSI  software  task,  MTISIM,  receives  the  virtual  target  data  from  global  memory,  and 
processes  the  virtual  targets  that  fall  within  the  MTI  dwell.  This  task  “detects”  virtual  targets  based  on 
target  probability  of  detection  (Pd),  velocity,  and  terrain  and  generates  a  combined  MTI  report 
containing  virtual  and  real  targets  (in  mixed  mode).  MTISIM  performs  the  following  major  operations: 

•  Processes  the  MTI  parameters  message  and  identifies  the  4km  by  4  km  grids  encompassed 
within  an  MTI  dwell. 

•  Builds  the  MTI  dwell  data  stmcture.  (RSR  ID,  Number  of  Live  AOI,  PRJs,  MTI  resolution  , 
etc.,) 

•  Determines  if  any  ‘Live”  MTI  targets  must  be  loaded  into  the  combined  JADS  MTI  Target 
Report 

•  Determines  if  any  Virtual  MTI  targets  must  be  loaded  into  the  combined  JADS  MTI  Target 
Report 

•  Applies  Probability  of  Detection  (Pd)  and  Target  Location  Circular  Error  Probability  (CEP) 
statistics  (see  Reference  4  and  Section  0),  and  Terrain  Screening  tests  for  each  of  the  Virtual 
targets  located  within  those  4x4  km.  grids  which  are  within  the  Radar  footprint. 

•  Issues  the  combined  JADS  MTI  Target  Report  to  the  Operator  Work  Stations  and  to  the 
SCDL  interface. 

The  two  most  observable  performance  characteristics  of  target  reports  from  the  Radar  are  Pd  and  target 
location  accuracy.  The  high  fidelity  Pd  computation  accounts  for  the  various  target  to  noise  ratio  losses 
and  processing  gains  characterizing  the  Radar,  the  environmental  conditions  and  the  geometric 
relationship  of  the  target  to  the  Radar  scan.  The  Pd  calculation  was  fine  tuned  based  on  actual  JSTARS 
System  Level  Performance  Verification  (SLPV)  flight  test  data,  (see  Section  5).  An  analysis  of 
controlled  SLPV  flight  test  data  provided  the  best  insight  into  the  actual  errors  that  were  modeled  for 
the  JADS  simulation. 

An  example  of  the  comparison  between  SLPV  flight  test  data  and  the  JADS  simulation  is  shown  below 
in  Figure  4.6  for  twelve  distinct  SLPV  Test  Points.  The  chart  shows  that  the  JADS  estimate  of  Pd  was 
slightly  more  optimistic  than  the  flight  data  (on  average  about  3-4%).  This  can  easily  be  attributed  to 
errors  in  the  assumptions  of  target  size  and  environmental  conditions. 
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Figure  45  Comparison  of  <Jfor  JADS  Simulation  and  SLPV  Flight  Test  Data 

MTI  target  location  error  statistics  derived  from  flie  1  sigma  errors  in  range,  cone  angle,  vertical 
separation  and  coordinates  also  were  applied.  These  were  derived  from  a  two  dimensional  theoretical 
model  and  from  SLPV  flight  data  taken  under  controlled  conditions.  The  down  range,  cross  range  and 
Circular  Error  Probability  (CEP)  statistics  were  utilized  in  the  JADS  CEP  algorithms  and  applied  to  the 
JADS  virtual  targets  based  on  their  true  range  and  angle  to  the  aircraft. 

Figure  4.7  below  provides  an  example  illustrating  the  close  similarity  in  the  frequency  distributions  of 
cross  range  error  for  the  Live  data  that  was  derived  from  SLPV  flight  data,  and  the  corresponding  cross 
range  error  from  the  JADS  simulation. 
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Live  X-Rng  Error  -  TP004 


I  Frequency 


Cross  Ranae  Error 


Figure  4Z  Cross  range  error  distributions  for  Flight  Test  Data  and  JADS  Simulation  Data 

Radial  Velocity  quality  and  error  statistics  also  were  derived  from  data  collected  under  controlled 
conditions  during  SLPV  flight  tests.  A  more  detailed  description  of  all  these  analyses  and  results  is 
presented  in  Section  5  of  this  report. 

The  MTI  simulation  software  tasks  operate  as  follows  in  the  laboratory  version:  The  JSTARS  software 
task,  PK8RSC  (radar  sensor  control),  commanded  by  receipt  of  a  Radar  Service  Request  (RSR), 
sends  Primary  Mode  Control  (PMC)  messages  to  the  VSTARS  task,  RCUSIM,  which  generates  and 
sends  Radar  Auxiliary  Data  messages  to  the  JSTARS  Radar  Data  Processor  (RDP)  MOCOMP  task, 
PK2MCP.  The  VSTARS  task,  PSPSIM  receives  MTI  parameters  message  from  PK2MCP  and 
generates  and  forwards  an  MTI  node  1  report  with  random  ra(^  hits  representing  live  (noise  in  the 
laboratory  version)  MTI  data  to  the  JSTARS  RDO  task,  PK4MTI,  which  provides  a  Target 
Association  report  to  PSPSIM.  PSPSIM  then  provides  a  Live  MTI  “node  2  report”  to  the  JSTARS 
task,  PK4RPT,  from  which  after  coordinate  conversion  (range-angle  to  TCS)  and  formatting,  the  Live 
MTI  Report  is  sent  to  the  RPSI  task,  MTISIM.  MTISIM  also  receives  the  MTI  parameters  message 
from  PK2MCP.  MTISIM  processes  the  virtual  target  data  and  issues  the  combined  Live  and  Virtual 
MTI  Target  Report  to  the  Operator  Work  Station  for  display. 
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4.2.4  SAR  Processing  Simulation 


The  SAR  simulation  which  was  designed  for  the  laboratory  version  of  the  RPSI,  is  illustrated  in  Figure 
4.8  which  shows  the  major  software  tasks  and  message  flow.  When  a  SAR  image  is  requested  the 
RPSI  generates  realistic  SAR  images  using  a  Lockheed  Martin  software  product  (Advanced  Radar 
Imaging  Emulation  System,  ARIES),  which  is  integrated  with  the  NG  RPSI  software. 


Figure  48  RPSI  SAR  Mode  Processing  Simulation  (Laboratory  Mode) 


When  a  SAR  image  is  requested,  for  a  particular  SAR  area  of  interest  (AOI),  the  new  RPSI  software 
task,  SARSEM,  receives  the  SAR  Mid  Array  message  from  MTISIM,  and  if  the  SAR  is  in  a  “virtual 
area”,  sends  a  SAR  Simulation  Parameters  message  to  ARIES  software  modules  (see  Reference  5). 
The  SAR  Simulation  Parameters  message  contains  the  SAR  image  request  and  the  operational  and 
navigational  data  including  the  AOI,  sensor  parameters  (resolution,  wavelength,  dwell  time,  coverage 
width,  range  extent,  antenna  orientation),  platform  state  data,  and  target  information.  ARIES  generates 
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the  simulated  SAR  images  from  Digital  Teirain  Elevation  and  Feature  data  bases  for  the  AOI.  ARIES 
takes  this  data  and  SAR  parameters  and  develops  a  point  map  for  locating  terrain  features  including 
elevation  and  targets  in  the  image.  It  then  uses  this  map  to  perform  a  3-D  to  2-D  projection  that 
simulates  what  would  be  seen  in  the  actual  Radar  Subsystem. 

A  height  parameter  is  used  to  generate  obscuration,  shadows  and  surface  gain  reflectivity,  including 
edge  reflectivity  effects.  Virtual  targets,  textures,  and  features  are  inserted  into  the  image.  Moving 
Targets  are  inserted  last  into  the  image.  Image  processing  of  this  “raw”  image  blends  edges,  seams  and 
boundaries.  A  simulated  SAR  Image  Report  that  contains  an  image  of  the  virtual  area  which  was 
indicated  in  the  SAR  Simulations  Parameters  message,  then  is  returned  to  SARSM.  SARSIM  scan 
converts  the  SAR  images  from  “range-dopplei'’  coordinates  to  the  X-Y  pixel  display  format,  and  sends 
the  images  to  the  OWSs,  and  to  die  Operations  and  Control  (OCO)  CPCl  when  required  for 
transmission  via  the  SCDL. 

The  SAR  simulation  software  tasks  operate  as  follows:  When  the  JSTARS  task,  PK8RSC  (radar 
sensor  control)  receives  the  RSR  for  a  SAR  image,  it  sends  primary  mode  control  messages  to  the 
VSTARS  task,  RCUSIM,  which  generates  and  sends  Radar  Auxiliary  Data  messages  to  the  JSTARS 
RDO  MOCOMP  task,  PK2MCP.  PK2MCP  sends  SAR  parameters  and  mid-array  messages  to 
PSPSIM  and  to  MTISIM.  PSPSM  generates  “Live”  (fake  data,  derived  from  noise  in  the  laboratory 
version)  SAR  data  blocks.  The  RDO  task  PK4SAR,  receives  these  multiple  blocks  and  formats  the 
“Live”  SAR  images.  These  images  are  then  sent  to  the  RPSI  task,  SARSIM.  If  the  SAR  has  been 
requested  for  a  “live”  area  this  live  SAR  is  forwarded  to  the  OWS.  Otherwise  it  is  “dumped”. 

MTISIM  loads  dwell  data,  determines  the  virtual  targets  within  the  SAR  Area  of  Interest  (AOI),  and 
determines  whether  the  requested  SAR  is  in  a  “Virtual”  or  a  “Live”  AOI.  When  the  requested  SAR  is  in 
a  Virtual  area  MTISIM  sends  to  the  RPSI  task,  SARSIM,  a  new  SAR  parameters  message  containing 
the  dwell  data  and  mid  array  messages,  and  the  virtual  targets  within  the  SAR  AOI.  When  a  SAR  has 
been  requested  for  a  “virtual  “  area,  SARSIM  sends  the  SAR  Simulation  Parameters  message  to 
ARIES,  and  ARIES  generates  the  simulated  SAR  as  described  above. 

The  ARIES  and  SARSIM  software,  and  modified  versions  of  PK2MCP,  PK4SAR  and  PK5SRM  will 
be  migrated  to  the  E-8C  PME  during  JADS  Phase  2.  PK5SRM  is  the  Radar  Service  Request  Manager 
software  task. 
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4.2.5  Navigation  Simulation  Processing 

In  the  E-8C  platform,  navigation  sensor  information  is  provided  to  the  Radar  subsystem  by  the 
navigation  sensors.  The  navigation  simulation  process  which  was  designed  for  ground  and  laboratory 
usage  of  the  RPSI  is  illustrated  in  Figure  4.9. 


Platform 

position 

velocity  and  attitude 


PTRNAV 

(SM&C) 


OWS  LAN 


ATWS 


PTRNAV 

(RDP) 


Figure  49  Navigation  Simulation  Processing 

This  process,  NAVSIM,  simulates  the  various  navigation  sensors  (GPS,  ESfUs,  IMG  and  CADCs)  of 
the  E-8C  aircraft  and  thereby  provides  the  needed  navigation  information  to  the  RPSI.  NAVSIM  also 
generates  and  provides  simulated  aircraft  position  and  velocity  (as  an  aircraft  PDU)  to  the  DISNIU. 
Although  NAVSIM  will  not  be  required  for  the  aircraft  version  of  the  RPSI  when  the  aircraft  is  flying 
(since  the  actual  navigation  sensors  will  be  employed),  it  is  expected  that  for  ground  tests  of  the  RPSI  in 
the  PME,  NAVSIM  will  be  utilized. 

NAVSIM  simulates  and  provides  this  navigation  sensor  data  to  the  JSTARS  software  task,  PUNRNG 
which  normally  executes  in  an  SM  &  C  computer  of  the  E-8C  PME.  PUNRNG  was  modified  for 
JADS  and  replicated  in  one  of  the  ALPHA  600s  (Figure  4.4).  PUNRNG  filters  and  merges  the 
navigation  sensors  data  and  provides  platform  position,  velocity  and  attitude  data  to  the  JSTARS  task, 
PTRNAV  for  use  in  the  RPSI  MTI  and  SAR  processing.  PTRNAV  normally  executes  m  the  SM&C 
and  the  RDP  of  the  JSTARS  PME,  and  was  replicated  in  the  ALPHA  600.  Platform  location  data  also 
are  provided  to  the  ATWS  for  display  of  the  navigation  data  and  a  depiction  of  the  orbiting  aircraft.  The 
platform  position  and  velocity  data  also  is  made  available  for  periodic  (currently  set  at  once  per  second) 
formatting  and  transmission  of  aircraft  PDUs  to  the  ADRNIU,  for  transmission  to  the  GNDNIU  and 
thence  to  the  DIS  network.  (See  Paragraph  4.2.2). 
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4.2.6  Data  Link  Interface  Design  (SCDL) 

In  the  laboratory  version  of  the  RPSI,  a  Databus  Datalink  Interface  Unit  was  developed  to  enable  the 
transmission  of  Surveillance  and  Control  Data  Link  (SCDL)  traffic  (e.g.,  MTI  and  SAR  reports)  to  an 
Army  ground  station  such  as  a  Groimd  Station  Module  (GSM)  or  Common  Ground  Station  (CGS),  or 
rephca  (GSMR)  of  such,  and  to  enable  reception  by  VSTARS  of  Radar  service  requests  (RSR)  from 
the  ground  station. 

In  the  E-8C  aircraft  SCDL  traffic  is  accommodated  by  a  1553B  data  bus  between  the  Central  Data 
Processor  (CDP)  and  the  SCDL  Air  Data  Terminal  (ADT),  which  interfaces  with  the  ground  station  via 
an  RF  Unk.  See  Figure  4.1.  The  Datalink  Communications  Management  CPCI,  (DCM)  controls  and 
monitors  the  equipment  in  the  datalink  subsystem  and  provides  for  bi-directional  communications.  DCM 
software  normally  executes  in  the  Central  Data  Processor  (CDP)  and  the  OWSs  of  the  Operations  and 
Control  (O&C)  Subsystem.  DCM  interfaces  to  the  SCDL  ADT  via  the  1553  digital  data  bus  (DDB) 
interface  task,  PTBDDB,  and  this  allows  the  ADT  to  communicate  with  the  JSTARS  Radar  and  O&C 
subsystems. 

For  the  laboratory  version  of  the  RPSI,  the  1553B  interface  was  bypassed  and  instead  of  the  RF  hnk,  a 
LAN  and  T1  communications  services  were  utilized  as  the  communications  media  between  VSTARS  in 
the  Northrop  Grumman,  Melbourne,  FI.  laboratory,  and  the  Motorola  GSM  replica  in  Phoenix,  Az. 
During  JADS  Phase  2  this  communication  will  be  fix»m  NG  to  the  GSMR  which  wiU  be  located  at  Fort 
Hood.  The  simulation  of  the  SCDL  interface  and  communication  is  illustrated  in  Figure  4.10. 

Existing  JSTARS  CPCI,  DCM,  and  task,  PTBDDB,  which  provide  for  the  SCDL  communications  in 
the  E-8C  platform,  were  modified  and  repHcated  in  one  of  the  ALPHA  600s.  Two  additional  JADS 
software  tasks  (JDSRCV  and  JDSXMT)  were  designed  to  interface  these  fimctions  and  the  T1  LAN. 

The  JADS  SCDL  interface  operates  as  follows: 

Modified  SEM  process,  PTBDDB  performs  the  following  functions 

•  Determines  if  JADS  SCDL  T1  LAN  interface  software  is  executing. 

•  Stops  all  I/O  which  normally  executes  to  the  SCDL  DDB  1553B  card  on  the  CDP,  when 
JDSXMT  and  JDSRCV  are  executing. 

•  Reroutes  SCDL  Downlink  messages  (e.g.  MTI  and  SAR  reports)  from  the  DCM  CPCI  to  the 
JADS  Transmit  (JDSXMT)  process. 

•  Forwards  all  SCDL  Uplink  messages  from  the  JADS  SCDL  Receive  process  (JDSRCV)  to 
the  DCM  CPCI  process  PW5SUM. 

•  Simulates  SCDL  ADT  fimctions  to  satisfy  JSTARS  software  that  the  SCDL  ADT  is  operational 
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Figure  4.0  SCDL  Simulation  (Laboratory  Mode  Only) 

The  JADS  SCDL  software  tasks  perform  the  following  ftmctions: 

•  JADS  SCDL  TRANSMIT  PROCESS  JDSXMT: 

•  Reads  Initialization  parameters  to  determine  which  User  Datagram  Protocol  (UDP)  port  is 
used  for  transmission,  and  the  Motorola  GSMR  SCDL  ADT  Internet  Protocol  (IP) 
address. 

•  Notifies  PTBDDB  of  JDSXMT  execution  status  via  message  at  process  initialization  and 
shutdown. 

•  Transmits  SCDL  DDB  messages  from  the  PW5SDM  process  to  the  Motorola  GSMR 
SCDL  T1  LAN  via  UDP 

•  Performs  UDP  socket  cleanup  and  process  shutdown 

•  JADS  SCDL  RECEIVE  PROCESS  JDSRCV; 

•  Reads  Initialization  parameters  to  determine  which  UDP  port  is  used  for  reception,  and  the 
Motorola  GSMR  SCDL  ADT  IP  address. 

•  Notifies  PTBDDB  of  JDSRCV  execution  status  via  message  at  process  initialization  and 
shutdown. 

PW5SUM  receives  via  UDP  all  SCDL  T1  LAN  messages  from  the  Motorola  GSMR 
SCDL  Ground  ADT  simulator  via  the  SCDL  T1  LAN. 
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•  Forwards  all  SCDL  T1  LAN  messages  to  the  PTBDDB  process  for  processing  by  the 
DCM  CPCI. 

•  Performs  UDP  socket  cleanup  and  process  shutdown. 

The  JADS  software  tasks,  JDSRCV  and  JDSXMT,  will  not  be  required  in  the  aircraft.  The  functions 
which  provide  for  SCDL  data  link  in  the  aircraft  already  form  a  part  of  the  JSTARS  software. 

4.2.7  Future  RF  Link  Requirements,  Design  and  Performance  Prediction 

In  order  for  the  RPSI  DISNIU  to  be  implemented  in  the  future  in  the  E-8C  PME,  an  RF  link  must  be 
established  between  the  AIRNIU  (See  Paragraph  4.2.2)  and  the  GRNDNIU.  This  link  will  provide  for 
the  transmittal  of  virtual  target  data  (via  entity  state  PDU)  firom  a  ground  site  (designated  as  the 
Northrop  Grumman  laboratory  in  Melbourne,  FL)  to  an  E-8C  aircraft  in  flight,  and  for  the  transmittal  of 
E-8C  PDU  firom  the  aircraft  to  the  groimd  site.  In  the  follow  on  JADSA^STARS  work  phases, 
Northrop  Grumman  will  provide  system  and  software  support  to  develop  this  RF  Link  Interface. 

During  JADS  Phase  lb,  Northrop  Grumman  supported  the  Government  in  running  message  load  tests  to 
establish  the  basic  RF  bandwidth  requirements  for  the  RF  link  design  (see  Reference  10).  Other  tests 
were  conducted  which  confirmed  the  ability  of  the  GRNDNIU  to  accommodate  the  receipt  of  PDUs  at 
rates  up  to  1100  PDUs  per  second.  This  is  greater  than  the  bandwidth  capabilities  of  a  T1 
communication  service  (estimated  at  approximately  350  PDUs/second).  This  rate  also  is  much  higher 
than  the  anticipated  rate  (estimated  at  less  than  100  PDU  per  second),  at  which  PDUs  will  be  issued 
fi-om  DIS  or  to  the  aircraft.  This  was  tested  by  replaying  PDUs  fi’om  the  SGI  logger  at  various  rates  and 
viewing  on  the  OWS  display  a  table  indicating  the  count  and  receipt  of  PDUs  by  the  GNIU. 

In  advance  of  the  planned  Phase  2  work,  RF  link  studies  also  were  conducted  during  the  development 
of  VSTARS,  and  resulted  in  the  selection  of  the  E-8C  (“Contingency  Enhancements”)  UHF  SATCOM 
system  and  equivalent  ground  site  SATCOM  components  as  the  recommended  baseline  hardware 
system  and  software  for  this  link.  This  recommendation  was  driven  by  the  following  requirements: 

•  The  link  not  be  limited  by  line  of  sight  considerations; 

•  The  link  should  be  implemented  as  much  as  possible  with  existing  aircraft  and  ground  site 
hardware  and  software. 


Figure  4.1 1  illustrates  the  recommended  concept  of  operation  of  the  DISNIU  RF  link.  Virtual  target 
PDUs  will  be  received  fi'om  the  DIS  network  by  the  Ground  DISNIU  in  the  Alpha  600,  via  the  T1 
communication  service  and  an  Ethernet  LAN  in  the  NG ITF.  After  processing  (see  Paragraph  4.2.2)  in 
the  GRNDNIU,  the  virtual  target  information  will  be  passed  to  a  ground  station  SATCOM  system  in 
the  ITF,  formatted,  and  transmitted  via  the  SATCOM  RF  link  to  the  E-8C  aircraft.  The  airborne 
SATCOM  subsystem  will  extract  the  virtual  target  data  and  pass  it  to  the  AIRNIU  in  the  RPSI  in  the 
PME,  where  the  data  will  be  processed  as  described  in  Paragraph  0.  E-8C  ES  PDUs  will  be  formed  in 
the  RPSI  and  periodically  forwarded  to  the  ground  site  GNIU  via  the  same  SATCOM  downlink. 
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RF  LINK  INTERFACE 


Figure  4L1 SATCOM  Will  Provide  the  RF  Link  Between  the  GNDNIU  and  the  AIRNIU 
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4.2.8  E-8C  SATCOM  System  Overview  and  Study  Recommendations 

Figure  4.12  shows  the  major  functional  components  of  the  current  E-8C  “Contingency  Enhancements” 
SATCOM  hardware  suite,  as  recommended  for  JADS.  Other  components  in  the  SATCOM  suite  that 
are  not  required  for  JADS  are  not  shown.  The  primary  elements  of  the  SATCOM  subsystem  include  a 
UHF  antenna,  a  Multi-mission  UHF  Satellite  Transceiver,  a  Data  Encryption  Unit,  a  SATCOM 
Processor/Computer,  an  ALPHA  workstation  and  an  OWS  LAN  interface  to  the  Joint  STARS  Radar 
System. 

The  E-8C  SATCOM  subsystem  currently  can  provide  a  secure,  over  the  horizon  communications  hnk, 
to  transmit  navigation  and  RADAR  MTI  and  SAR  data  from  the  aircraft  to  a  ground  station,  as  well  as 
to  transmit  messages  from  a  ground  site  to  the  aircraft.  The  aircraft  utilizes  two  different  SATCOM 
systems.  It  is  intended  to  utilize  one  of  these  systems,  with  modified  software  to  accommodate  the 
JADS  RPSl  RF  link  requirements  in  the  aircraft.  An  equivalent  suite  of  hardware  will  be  utilized  for  the 
ground  site  portion  of  this  RF  link  in  the  Northrop  Grumman  ITF. 


Figure  <42  Major  Hardware  Components  of  the  SATCOM  Subsystem  in  the 

E-8C  Aircraft 

In  addition  to  the  use  of  this  existing  SATCOM  system  hardware,  software  must  be  developed  to 
accommodate  tire  special  requirements  of  the  JADS/RPSI  system.  During  Phase  lb,  the  existing  E-8C 
SATCOM  hardware,  software  and  operational  concepts  were  reviewed.  In  current  Joint  STARS 
operation,  SATCOM  usage  involves  communication  between  the  aircraft  SATCOM  station  and 
multiple  ground  stations.  The  aircraft  operates  as  the  primary  station  and  controls  the  network  linking  the 
aircraft  to  the  ground  stations.  The  ground  stations  are  referred  to  as  “secondary  stations”  and  are  under 
the  control  of  the  aircraft.  Control  of  the  ground  stations  is  effected  by  polling  by  the  aircraft  station. 
Associated  with  this  polling  is  a  significant  reduction  in  chaimel  efficiency.  Most  of  the  data  traffic  over 
the  network  is  transmitted  from  the  aircraft  and  the  communication  protocol  design  is  heavily  biased  in 
favor  of  the  down-link  traffic.  The  up-link  traffic  to  the  aircraft  generally  is  limited  to  a  low  volume  of 
data.  (See  reference  1 1). 
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For  JADS/RPSI  the  situation  is  quite  different.  For  JADS,  most  of  the  data  traffic  will  be  from  a  single 
ground  site  to  the  aircraft,  (to  convey  the  DIS  ES  PDU,  at  a  nominal  rate  of  100  PDU/second  to  the 
aircraft).The  lesser  traffic  will  be  from  the  aircraft  to  the  ground  site,  (to  convey  the  aircraft  ES  PDU  to 
the  ground  site  and  thence  to  the  DIS  network,  at  a  nominal  rate  of  one  (1)  PDU/second,  or  less).  The 
JADS  RPSI  does  not  require  the  multi-station  polling  that  is  employed  in  Joint  STARS.  By  eliminating 
this  polling  for  the  RPSI  by  modification  of  the  SATCOM  protocol,  significant  transmission  channel 
efficiency  may  be  realized.  A  study  will  be  conducted  during  Phase  2  to  determine  the  best  design 
modifications  for  VSTARS. 

The  existing  Joint  STARS  SATCOM  protocol  utilizes  a  Transport  Layer  apphcation  data  packing 
format,  which  is  tailored  to  the  current  “contingency  enhancements”  Joint  STARS  apphcation.  This 
transport  layer  currently  can  accommodate  600  octets  of  apphcation  data.  As  such,  it  could 
accommodate  up  to  25  stripped  (192  bit)  PDUs  per  fimne.  It  is  intended  that  during  the  planned  follow 
on  JADS  phases  the  design  of  the  software  for  RPSI  usage  of  SATCOM  will  be  preceded  by  a 
detailed  review  of  this  existing  SATCOM  software  design.  Communication  protocol,  software  design, 
and  timing  wih  be  reviewed.  Then  a  JADS  version  can  be  designed,  based  on  a  best  mix  of  existing 
SATCOM  software  and  any  necessary  modifications  to  accommodate  the  requirement  to  link  PDUs 
between  the  aircraft  and  the  ground  site  at  the  maximum  data  rates  achievable,  consistent  with 
acceptable  performance  (e.g.,  data  error  rates)  of  the  SATCOM  link.  These  issues  are  discussed 
further  below. 

4.2.9  SATCOM  Performance  Considerations 

During  the  execution  of  a  JADS/DIS  “battle  scenario”  the  number  of  entity  state  PDU,  which  the  RPSI 
must  receive  from  DIS,  has  been  estimated  at  upward  to  100  PDUs  per  second  (>19,000  data  bits  per 
second,  based  on  192  bits/PDU,  plus  overhead).  Although  this  PDU  rate  is  a  variable  and  can  be 
controlled  somewhat  by  judicious  design  of  the  scenario,  it  is  desirable  to  design  the  SATCOM  RF  link 
software,  and  to  select  the  system  parameters  and  operating  modes  to  accommodate  a  PDU  rate  as 
high  as  possible,  consistent  with  an  acceptable  limit  on  the  number  of  errors  in  the  PDU  data. 

A  useful  measure  of  goodness  for  the  performance  or  quality  of  a  communications  link  is  file 
Throughput,  e.g.,  the  rate  at  which  data  can  be  transmitted  and  received  at  acceptable  data  or  message 
error  rates.  For  the  JADS  RPSI  SATCOM  link,  performance  can  be  predicted  by  a  consideration  of 
the  design  of  the  hardware  and  software  of  the  various  SATCOM  system  elements  (air,  ground  and 
satellite)  and  of  the  expected  characteristics  of  the  RF  transmission  paths. 

Given  the  selection  of  the  existing  SATCOM  system  hardware  in  the  aircraft,  an  equivalent  SATCOM 
system  at  the  ground  site,  and  candidate  UHF  satelhtes,  the  SATCOM  link  can  be  analyzed  to  provide 
a  link  budget  analysis.  The  quahty  of  the  link  can  be  expressed  in  terms  of  the  expected  signal  to  noise 
ratio  and  the  bit  error  rate  (BER)  for  file  total  link  (i.e.,  ground  site  to  satelhte  to  aircraft).  An  example  is 
the  space  link  from  the  ground  site  at  the  Northrop  Grumman  ITF  in  Melbourne,  FL,  to  a  selected  UHF 
satelhte,  and  then  to  the  E-8C  aircraft  flying  near  Fort  Irwin  in  California.  Performance  can  be  predicted 
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as  a  function  of  the  data  transmission  bit  rate,  modulation  mode  (e.g.,  BPSK,  QPSK  etc.,),  the  details 
of  candidate  communications  protocol,  propagation  conditions,  and  hardware  processing  parameters.. 

A  preliminary  analysis  such  as  this  was  conducted  in  Phase  lb  for  a  selected  UHF  satellite  (UHF 
Follow  -On,  UFO  @100  deg.  W  longitude),  a  ground  station  at  the  Northrop  Grumman,  ITF  in 
Melbourne,  FI.  and  an  E-8C  aircraft  flying  near  Fort  Irwin,  Ca.  The  results  are  shown  in  Table  4.3.  This 
analysis  will  be  refined  in  phase  2.  For  the  example  postulated  parameter  set,  satellite  type,  locations  of 
the  ground  based  SATCOM  system  and  the  E-8C  aircraft,  this  preliminary  analysis  indicates  a 
composite  Eb/No=9.09  dB,  (ratio  of  the  energy  per  information  bit  of  the  input  PSK  signal  to  the  noise 
power  per  Hz.)  for  the  entire  link  as  received  by  the  aircraft..  This  corresponds  to  a  theoretical  BER 
performance  of  approximately  2*10‘^. 

The  expected  message  error  rate  (e.g.,  the  PDU  error  or  loss  rate)  can  be  estimated  from  a 
consideration  of  the  predicted  BER  and  selected  candidate  (software)  protocols  for  transmission  of  the 
PDU,  and  the  logic  which  is  employed  by  the  software  when  bit  errors  occur.  As  a  result  of  this  initial 
analysis  a  software  design  will  be  selected,  implemented,  and  tested  in  the  Northrop  Grumman 
laboratory  with  SATCOM  system  components,  in  order  to  confirm  the  results  of  the  analysis  and/or 
refine  the  expected  performance.  It  is  intended  that  the  planned  follow  on  JADS  phase  2  activities  will 
complete  this  analysis  and  design  and  also  will  include  laboratory  tests  of  the  RF  Unk,  utilizing  different 
modulation  methods  (e.g.,  BPSK  &  QPSK  variants)  and  data  rates,  and  for  different  versions  of 
available  UHF  satellites. 

The  results  of  tiiese  analyses,  tests  and  a  recommended  software  design  will  be  reviewed  with  the 
Customer  for  concurrence  in  the  design  and  recommended  operating  mode.  This  will  provide  the 
Customer  with  an  early  opportunity  to  consider  tailoring  the  JADS  battle  scenario  so  that  the  PDU  rates 
are  selected  to  be  consistent  with  the  capability  of  the  RF  link. 


D 


30 


Table  43  Preliminary  Analysis  of  SATCOM  Link  Budget 

gAfcdii  "  '  "link  from  Melbourne,  fl  to  aTtc 
iCALCULATIONS  near  Fort  IRWIN,  Califo^ 


a.  NOISE  TEMP  SATELLITE 

DEGREES  K 

290 

aa.  Rain  Effects  Tr 

DEGREES  K 

0.00 

b.  NOISE  TEMP  Aircraft  TEMP 

DEGREES  K 

865.17 

c.  EIRP  SATELLITE  MAX 

dBw,  ENTER  DATA 

iSvvAvVt!'''" 

d.  TEST  TONE  DEVIATION 

kHz,  ENTER  DATA 

NA 

e.  MAX  SIGNALING  FREQ 

kHz,  ENTER  DATA 

(N/A) 

f.  Rec.  WAVELENGTH 

METERS 

1.149425 

g.  REQUIRED  Eb/Nofor  lO'^-S 

dBw,  ENTER  DATA 

(N/A) 

h.  INDEX  MODULATION  (m) 

NO  UNITS 

NA 

i.  I.F.  BANDWIDTH 

kHz 

* 

j.  NOISE  POWER 

dBw 

-155,25 

k.  SNR  REQUIRED 

dBW 

8.503612 

************************************************************************************** 

UPLINK  CALCULATIONS 

Terminal 

Melbourne 

TRANSMITTED  FROM  MELBOURNE 

(28  deg.  N,  80  deg.  W) 

1.  TRANSMIT  WAVELENGTH 

METERS 

1.016949 

m.  TRANSMIT  POWER 

WATTS 

n.  TRANSMIT  POWER 

dBw 

20 

0.  ANTENNA  GAIN  Tx 

dBi 

|2  ' 

p.  TRANSMIT  EIRP 

dBw 

32 

******************************************************************************************* 

RECEIVED  @  SATELLITE  (UFO) 

(0  deg.  N,  100  deg.  W) 

q.  PATH  LOSS  XMIT 

dB 

173.2316 

r.  GAIN  OF  1  m  SQ  ANTENNA 

dB/m2 

10.84611 

s.  MISC  LOSSES 

dB 

t.  OPERATING  FLUX  @  SATELLITE 

-132.386 

u.  SATELLITE  FLUX  DENSITY 

dbW/m2,  'ENTER  DATA  ,  '  f 

-110 

V.  INPUT  BACK-OFF 

dB 

22.38551 

w.  SATELLITE  Gsat/T  pFO) 

dB/k 

X.  MISC.  U/L  LOSS  L 

dB 

0 

y.  B/Oi 

dB 

0 

z.  C/Nu 

dB 

27.08897 

zz.  Limiter  Enhancement 

dB 

3.003747 

z1  Cumulative  C/Nu  +  Lim. 

dB 

30.09272 

L?2'.Eb/No'  "  "  • 

,31.23911'  ; 

■z3d/No  ■ 

74.07212 

Table  4.3  Continued  RECEIVED  AT  AIRCRAFT 

(36.6  deg  N,  117  deg  W) 
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aa.  ElRPs,sat 

dBw 

bb.  B/Oo 

dB 

0 

cc.  A/C  Receiver  Gain 

dB 

dd.  Gr/T 

dB/K 

-27.371 

ee.  MISC  LOSS  D/L  L’ 

dB 

6 

ff.  EIRP  attrib.  to  carrier 

dB 

28.99575 

gg.  C/Nd 

_dB^_^^ .  . 

7.971866 

p.Eb/No' 

COMPOSITE  C/N  CALCULATION 

STEP  1  C/Nu 

1021.579 

STEP  2  C/Nd 

6.268832 

STEP  3  1/(C/Nu) 

0.000979 

STEP  4  1/(C/Nd) 

0.159519 

STEP  5  1/(C/Nn)  +  1/(C/Nd) 

0.160498 

gg.  COMPOSITE  C/N  FOR  ENTIRE  LINK 

7.945297 

;hh.  Composite  Eb/No  FOR 

dB 

■  “^9' 091 685  ' 

IpTlRE: LINK"r,';:;;ii®vr’; 
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5.  MTI  SIMULATION  TECHNIQUES 

5.1  Application  of  MTI  Pd  and  TC  Statistics 


This  section  is  intended  to  detail  flie  algorithms  and  techniques  which  were  utilized  to  implement  the 
Moving  Target  Indicator  (MTI)  probability  of  detection  (Pa)  and  target  classification  (TC)  statistics  for 
the  JADS  RPSI.  The  basis  of  this  work  was  derived  from  the  Phase  1  study  for  integrating  a  Radar 
Processor  Simulation  (RPS)  onto  the  Joint  STARS  platform.  The  results  of  the  study  have  been 
incorporated  in  reference  documents  2,  3  and  4. 

5.1.1  MTI  Pd  Requirements 

The  appUcation  of  MTI  target  statistics  is  fundamentally  related  to  target  signal-to-noise  (  T/N)  as 
derived  from  the  radar  range  equation  modified  to  include  Joint  STARS  radar  subsystem  specifics.  The 
Engineering  Design  Report  (EDR)  (see  reference  3),  required  radar  operating  curves  to  be  developed 
off  line.  These  relate  Joint  STARS  dwell  time,  azunuth  and  range  to  a  family  of  probability  of  detection 
(Pd)  and  T/N  levels.  The  analytical  basis  of  this  MTI  Pd  simulation  was  derived  from  a  Joint  STARS 
radar  performance  prediction  model  (JCONT)  developed  under  the  Full  Scale  Development  (FSD) 
program.  JCONT  is  a  non  real-time  tool  which  simulates  the  transmission,  reception  and  processing  of 
a  number  of  coherent  processing  intervals  (CPIs)  comprising  a  set  of  different  pulse  repetition 
firequencies  (PRFs)  of  specified  integration  length  and  azimuth  beam  spacing  used  to  detect  and  locate  a 
moving  target  in  a  clutter  background.  The  target  is  placed  in  the  desired  range  and  angle  location  and 
evaluated  over  a  range  of  radial  velocities.  For  each  CPI,  the  T/N  and  T/C  ratios  are  determined  for 
each  Doppler  filter  by  convolving  the  Doppler  filter  spectrum  against  the  combined  clutter,  noise  and 
target  spectra.  From  the  combined  clutter  and  noise  environment,  a  detection  threshold  is  determined 
that  will  allow  the  system  probabihty  of  false  alarm  (PFA)  to  be  met.  A  Swerling  I  target  model  is  used 
with  tile  detection  threshold  to  determine  target  Pd  for  each  CPI.  Assuming  each  CPI  represents  an 
independent  look  at  the  target,  a  composite  target  Pd  is  estabhshed  over  ‘N’  CPIs  using  an  ‘M’  out  of 
‘N’  detection  scheme. 

5.1.2  Target-to-Noise  (  T/N  )  vs  Pd 

Tests  using  JCONT  indicate  that  a  set  of  radar  operating  curves  can  be  developed  which  accurately 
relate  T/N  to  Pd  averaged  over  target  velocity  (Figure  5.3).  Since  the  Joint  STARS  radar  employs  a 
pseudo  low,  multiple  PRF  design,  some  PRFs  may  be  blind  in  range.  The  PRFs  have  been  selected 
such  that  at  most  only  one  PRF  will  be  completely  blind  in  range,  so  two  T/N  curves  have  been 
developed:  one  with  zero  blind  PRFs  and  the  other  with  one  blind  PRF.  When  only  a  portion  of  the  long 
pulse  is  lost  during  transmission,  tiie  desired  Pd  may  be  interpolated  between  these  two  curves. 
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5.1.3  Target  Radial  Velocit^O  vs  Pd 

The  relationship  of  to  Pa  varies  based  on  the  set  of  PRFs  used  to  reduce  the  effect  of  target  blind 
speeds  near  multiples  of  the  PRF.  Additional  tests  using  JCONT  show  that  the  magnitude  of  Pa  dips 
over  are  predictable  and  vary  with  or  equivalently,  average  Pa.  Since  the  location  and  magnitude 
of  these  Pa  dips  require  an  intimate  knowledge  of  the  relationship  of  T/N  and  T/C  in  a  Doppler  filter, 
this  type  of  processing  is  beyond  the  scope  of  a  real-time  simulation.  Instead,  a  reference  Pa  vs 
curve  has  been  developed  off  line  for  each  PRF  set  so  that  the  location  of  Pa  dips  are  known  and  their 
magnitude  can  be  predicted  using  a  range  rate  dip  factor  to  attenuate  the  dips  when  average  Pa  (=  T/N) 
is  higher  than  nominal,  and  to  enhance  the  dips  when  average  Pa  (=  T/N)  is  lower  than  nominal. 

5.1.4  Determination  of  T/N 

A  baseline  T/N  ratio  is  defined  in  dBm  consisting  of  the  constant  Joint  STARS  radar  system  gains  and 
losses,  fi-om  which  variable  gains  and  losses  based  on  target  geometry  and  scan  conditions  may  be 
added.  T/Nq  consists  of  classified  values  for  the  peak  transmit  power  (Pt),  peak  anteima  transmit  gain 
(Gt),  peak  antenna  receive  gain  (Gr),  processing  gain  (Gp),  transmit  duty  factor  (Df),  wavelength  (X), 
thermal  noise  factor  (kT),  fixed  receive  chain  losses  (Lrcv);  and  constant  terms  [2(47t)^  =  36  dBm]. 

T/No  =  P,  +  Gt  +  Gr  +  Gp  +  101og,o(Df)  +  301ogio(X)  -  kT  -  Lrev  -  36 

Lrcv  consists  of  fixed  allocated  losses  such  as  radome  loss,  noise  figure,  matched  filter  loss,  phase  noise, 
SPP  noise,  Doppler  filter  taper,  A  PRF  (waveform),  and  average  beam  pointing  loss. 

T/No  is  modified  based  on  specific  target  and  scan  conditions  such  as  the  targets  radar  cross  section 
(Ot),  Doppler  filter  bandwidth  (Dbw),  target  range  (Rt),  beam  broadening  loss  (Lscn),  atmospheric  loss 
(Lata),  elevation  pattern  loss  (Lepat),  beam  spacing  (Leo),  and  lens  loss  (Liens).  Each  of  these  losses  are 
computed  based  on  the  geometric  relationship  of  the  target  to  the  scan.  They  are  added  to  the  baseline 
T/N  to  obtain  the  following: 


T/Nt  =  T/No  +  Ot  -  lOlogio(Dbw)  -  401ogio(Rt)  -  (L  sen  Lata  Lepat  Leo  Liens) 

Other  losses  which  factor  into  T/Ntsuch  as  \  quantization  loss,  filter  scalloping  loss,  pulse  loss,  and 
CFAR  losses  vary  according  to  PRF  and  Doppler  filter  and  is  therefore  compensated  for  through 
application  of  the  range  rate  dip  factor  (9lf). 

5.1.5  Determination  of  Target  Pd  (Pdt) 

After  modifications  to  T/Nt  are  made,  the  target’s  average  Pa  over  SR  (AP*)  is  interpolated  fi'om  the 
radar  operating  curves  which  relate  Pa  to  T/N.  From  the  APat  a  range  rate  dip  factor  SRf  is  computed  to 
determine  the  actual  Pa  statistic  of  the  target  at  its  radial  velocity  SR  and  then  applied  as  follows  to  derive 
the  target’s  actual  Pa  (Pat). 
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9tf  =  1  +  lOlogio  ( APdr  /  APdt )  Pdt  =  APdt  +  X  ( Pdit  -  APdr ) 


where, 

APdr  :  Pd  averaged  over  for  the  reference  waveform. 

APdt  ;  Pd  averaged  over  for  the  target  interpolated  from  curves. 

Pdrt  :  Pd  for  the  target  from  the  reference  curve  at  9tf 

5.1.6  Computations  Made  Per  4x4  Km  Grid 

A  grid  filtering  technique  is  used  to  check  for  virtual  targets  within  the  radar  beam  foo^rint  by  first 
quantizing  all  virtual  targets  within  grids  of  4x4  Km.  When  the  set  of  4x4  Km  grids  within  the  beam 
have  been  selected,  some  pre-processing  of  MTI  Pd  statistics  are  accompHshed  at  the  grid  level.  Since 
this  represents  very  low  resolution  data,  information  about  this  area  cannot  change  rapidly  with  respect 
to  the  scan.  The  computations  made  per  grid  are  Latm,  Lepat,  and  Liens  and  are  applied  equally  to  all 
targets  within  the  grid. 

Atmospheric  loss  (Latm)  is  a  significant  T/N  loss  due  to  the  attenuation  of  the  radar  energy  through 
variable  atmospheric  conditions.  Following  the  Joint  STARS  System  Specification,  there  are  three  types 
of  weather  conditions  modeled:  (1)  clear  air,  (2)  clouds,  and  (3)  rain.  For  rain  conditions,  a  rain  rate  in 
mm/hr  is  defined.  Future  implementations  of  weather  PDUs  on  the  DIS  network  will  allow  for  more 
flexibility  concerning  weather,  but  for  this  phase  of  IADS,  the  operator  specifies  one  of  these  weather 
conditions  (Later  we  might  want  to  consider  a  graphical  user  interface  (GUT)  which  will  allow  the 
operator  to  define  weather  regions  mapped  to  grids).  Latm  is  the  sum  of  clear  air,  cloud,  rain  -i-  cloud  and 
rain  losses  over  which  the  beam  travels  both  ways  through  the  boundaries  of  each  weather  strata.  The 
boundaries  of  weather  strata  are  separated  by  altitudes  from  which  the  beams  projection  through  each 
layer  is  computed  and  a  constant  loss  (per  Km)  for  each  weather  strata  is  applied  over  twice  the 
distance  through  the  layer.  The  clear  air  loss  is  applied  for  the  entire  two  way  propagation  path  and  is 
currently  available  in  subroutine  SKRS90_ALOSS.  The  cloud  loss  is  defined  as  0.026  dB/Km  (from 
the  Joint  STARS  System  Specification)  and  is  applied  for  the  two  way  propagation  length  through 
clouds  if  the  weather  type  indicates  cloud  or  rain  conditions.  The  rain  loss  is  defined  from  Nathanson 
(Reference  9)  as  0.00809rr‘ where  ‘rr’  represents  the  rain  rate  in  mm/hr.  Subroutine 
MTISIM_ATM_LOSS  defines  the  mathematics  used  to  compute  these  losses  using  platform  altitude, 
latitude,  target  range,  and  grid  weather  as  inputs. 

Elevation  pattern  loss  (Lepat)  occurs  when  the  target  is  offset  from  the  antenna  elevation  boresight  and  is 
particularly  apparent  for  small  targets  (such  as  the  double  Doppler  component  of  the  TC  mode).  Given 
the  platform  altitude/orientation  and  the  antenna  orientation  (A-Matrix),  the  elevation  boresight  range  is 
computed  for  the  dwell.  The  range  of  the  grid  center  is  checked  against  a  Taylor  weighted  beam 
approximating  the  actual  antenna  elevation  pattern  to  determine  the  elevation  pattern  loss  for  all  targets 
within  that  grid.  Analysis  subroutines  TAYLORl  and  SANTVP  are  utilized  to  determine  Lepat- 
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Lens  loss  (Liens)  is  a  radar  refraction  loss  which  makes  the  atmosphere  behave  like  a  negative  lens, 
resulting  in  the  reduction  of  the  targets  apparent  size.  L^ns  is  interpolated  from  a  family  of  curves  relating 
grazing  angle  and  target  (i.e.  grid)  range  derived  from  the  January  1973  IEEE  paper  on  Atmospheric 
Lens  Effect.  Analysis  subroutine  LENSLOSS  is  available. 

Typical  losses  for  a  clear  weather  single  swath  condition  are  as  follows: 


Figure  51  Typical  Radar  Losses  for  Clear  Weather 
5.1.7  Computations  Made  Per  Dwell 

Some  radar  system  losses  vary  only  as  the  beam  scans  in  azimuth  and  can  be  considered  flie  same  for 
all  targets  within  that  beam. 

The  beam  broadening  loss  (Lscn)  occurs  from  electronically  steering  the  beam  in  azimuth,  and  for  the 
Joint  STARS  antenna  is  represented  by  the  closed  form  expression: 

Lscn  =  -201og,o  ( 5.67cos®  ^es  -  2.36cos0s  -  2.31 ) 

where, 

6s :  antenna  scan  angle  with  respect  to  boresight  (radians)  =  7t  -  ps- 
Ps :  antenna  cone  angle  with  respect  to  platform  heading  (radians). 

In  the  Joint  STARS  radar  design,  the  Doppler  filter  bandwidth  (Dbw)  and  azimuth  beam  spacing  varies 
as  a  function  of  Gg.  The  T/N  curves  were  derived  under  the  assumption  that  a  nominal  Dbw  and  two- 
way  6  dB  beam  spacing  were  used.  The  actual  Dbw  can  be  derived  from  the  number  of  integrated 
pulses  (Nint)  and  PRF  in  the  first  CPI  of  the  dwell  as 


Dbw  =  ?iPRF/(2Ni„0 


A  beam  spacing  factor  (BS^  can  be  computed  to  relate  the  actual  beam  spacing  back  to  the  two-way  6 
dB  beam  spacing.  From  this  factor  an  additional  beam  spacing  loss  (Leo)  analogous  to  the  azimuth 
beamshape  loss  can  be  derived  as  follows: 


where, 


Leo  =  -lOlogio  (  BSf)  BSf=  (j)d  cos6s  / 


(j)d  :  Beam  spacing  for  the  current  dwell  (radians). 

(|)b  :  Two-way  6  dB  beam  spacing  at  broadside  (radians). 


Typical  losses  for  a  dwell  as  a  function  of  angle  are  as  follows: 


T/N  Dwell  Computations 


Figure  S  Typical  Radar  losses  for  Dwell  vs  Angle  Computations  made  per  Target 
5.1.8  Computations  Made  Per  Target 

Computations  made  per  target  are  the  lowest  resolution  required  for  the  MTI  Pd  simulation.  The 
computations  made  per  target  are  target  range  (R«),  range  rate  (9tt).  radar  cross  section  (Ot),  terrain 
screening,  and  target  resolution. 


The  loss  due  to  target  range  is  401ogio(Rt).  Target  range  is  given  by: 


R.  =  [  (Tx  -  Px)'  +  (Ty  -  ?yf  +  (T^  -  P,)'  r 

where. 


T :  Target  Position  Vector  (in  TCS) 

P  :  Platform  Position  Vector  (in  TCS) 
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Target  range  rate  (9lt  :  radial  velocity)  is  derived  to  determine  if  the  target  is  in  a  Pa  notch  due  to 
Doppler  ambiguities  within  the  PRF  set.  Since  the  Pa  dips  are  considered  the  same  for  opening  and 
closing  targets,  the  absolute  value  of  is  used. 

%  =  -V,  •  (T  -  P)  /  Rt  Vt ;  Target  Velocity  Vector  (in  TCS) 

Target  radar  cross  section  (Ot)  is  expressed  in  dBm  as  lOlogio(RCSt)  when  RCSt  is  expressed  in  m^.  Ct 
will  be  die  default  value  for  primary  targets  in  the  Joint  STARS  System  Specification  For  TC  statistics, 
the  smaller  double  Doppler  Ot  is  used. 

Target  screening  occurs  when  a  target  is  obscured  along  the  radar  line-of-sight  by  a  physical  object. 
Determination  of  target  screening  is  done  by  comparing  the  target  line-of-sight  to  the  platform  with  the 
target  line-of-sight  in  the  Area  Visability  Database  (AVD).  Subroutine  STCAHO_GET_TAN_RTE 
accesses  the  AVD  and  reports  back  the  target  line-of-sight  to  the  horizon  based  on  the  azimuth  angle. 

Target  resolution  effects  target  detection  in  range,  azimuth  and  Doppler  space.  When  two  or  more 
targets  are  located  within  close  proximity,  the  radar  can  only  detect  one  of  those  targets.  Due  to  the 
scanning  nature  of  the  Joint  STARS  MTI  design,  target  resolution  constraints  in  azimuth  and  Doppler 
space  are  rare  because  the  target  can  be  seen  by  multiple  CPIs  at  different  azimuth  angles,  so  it  is  not 
necessary  to  model  these  constraints.  The  primary  constraint  on  target  resolution  is  the  distance 
between  targets  in  range.  Formal  system  level  tests  require  a  target  to  be  at  least  1.5  range  bins  fi'om 
another  target  to  insure  detection  capability,  but  a  target  may  be  detected  when  closer.  Variable  range 
resolution  effects  can  be  modeled  by  uniformly  selecting  a  range  resolution  based  on  range  bin  size 
between  0.75  and  1.5  range  bins  for  each  radar  dwell. 

5.1.9  Data  Analysis 

In  order  to  evaluate  this  modeling  technique,  two  data  analyses  have  been  performed.  First,  a 
theoretical  simulation  environmental  test  was  performed  to  evaluate  this  technique  against  the  non-real 
time  analysis  tool  JCONT.  The  second  analysis  compares  the  technique  with  actual  flight  data  taken 
under  controlled  conditions. 

5.1. 9.1  JCONT  Simulation 

The  advantage  of  performing  a  comparison  with  a  theoretical  test  environment  is  that  all  conditions  can 
be  controlled.  In  this  analysis,  100  test  points  were  randomly  selected  in  range,  azimufli,  and  weather, 
with  all  other  variables  set  to  a  nominal  value.  The  average  Pd  of  the  real-time  simulation  (JADS)  is 
compared  with  the  non-real-time  simulation  (JCONT).  The  statistics  show  that  the  average  Pd  error  is 
1.0%  with  a  standard  deviation  of  1.7%  and  the  average  T/N  error  is  0.3  dB  with  a  standard  deviation 
of  0.3  dB.  The  results  are  indicated  below  in  Figure  5.3 
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MTI  Pd  Simulation  Test  Results 


Figure  S  Compares  Pd  v.s.  T/N  of  JADS  &  JCONT  Simulations 
5.1.9.2  Flight  Data 

Analysis  of  flight  data  requires  as  many  variables  as  possible  to  be  controlled,  but  there  are  always 
unknown  system  conditions.  Formal  system  level  tests  are  designed  to  maximize  control  over  the 
variable  conditions  of  the  test,  so  these  tests  represent  the  best  data  set  for  comparison  of  the  JADS 
simulation  to  the  actual  system.  A  brief  comparison  between  SLPV  flight  data  and  the  JADS  simulation 
is  shown  below  for  twelve  distinct  SLPV  Test  Points.  The  JADS  estimate  of  Pd  assumes  clear 
weather  conditions  and  a  nominal  sized  target  with  a  Swerling  I  radar  cross  section  fluctuation.  The 
chart  shows  that  the  JADS  estimate  of  Pd  was  slightly  more  optimistic  than  the  flight  data  (on  average 
about  3-4%),  which  can  easily  be  attributed  to  errors  in  the  assumptions  of  variable  target  size  and  clear 
weather  conditions. 
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Figure  51  Compares  Pd  of  JADS  and  SPLV 
5.2  Application  of  MTI  CEP  Statistics 

This  section  is  intended  to  detail  the  algorithms  and  techniques  which  were  utilized  to  implement  the 
Moving  Target  Indicator  (MTI)  location  accuracy  statistics  for  the  Joint  Advanced  Distributed 
Simulation  (JADS)  environment  on  the  Joint  STARS  platform.  The  location  of  targets  detected  by  the 
Joint  STARS  radar  are  reported  relative  to  the  local  Topocentric  Coordinate  System  (TCS)  after 
coordiimte  conversion  from  range  and  angle.  Location  accuracy  is  measured  and  applied  using  the 
Circular  Error  Probability  (CEP)  method  based  on  the  targets  reported  position  versus  its  tme  position. 

An  overview  of  the  MTI  location  error  sources  is  provided  as  background  for  the  JADS  CEP 
algorithms.  From  these  error  sources,  a  two  dimensional  linear  model  of  down  range  and  cross  range 
errors  relates  traditional  I0  values  to  target  CEP.  The  down  range,  cross  range,  and  CEP  statistics 
observed  during  controlled  flight  tests  are  then  codified  to  the  JADS  CEP  algorithms  and  applied  to  the 
JADS  virtual  targets  based  on  their  tme  range  and  angle. 

5.2.1  MTI  CEP  Error  Sources 

The  application  of  MTI  target  location  error  statistics  is  derived  from  the  lo  errors  in  range,  cone  angle, 
vertical  separation  and  coordinates.  Range  error  sources  include  radar  range  measurement,  residual 
reflection  and  hardware.  Cone  angle  error  sources  include  interferometric  measurement  and  boresight 
corrections.  Vertical  separation  errors  primarily  derive  fl'om  platform  altitude  and  the  hypsographic 
database.  Coordinate  error  sources  include  navigation  position  and  coordinate  conversion.  The 
geometric  parameters  outlining  the  error  sources  are  defined  as  follows: 
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The  CEP  error  sources  are  input  into  a  linear  model  with  two  outputs;  a  down-range  error  and  a  cross¬ 
range  error,  where  each  output  is  a  linear  function  of  individual  error  contributors.  The  la  value  of  the 
individual  error  contributors  are  RSS’d,  and  CEP  is  calculated  for  the  uncorrelated  down  range  and  cross 
range  variables  as: 

•  X=inin(XrT)r)  Y=max(XrT)r) 

•  Linear  region:  XA">0.4:  CEP  =  0.560Y  +  0.617X 

•  Quadratic  region;  XA^<0.4:  CEP  =  0.674Y  +  0.128X  +  0.513X2A" 


Figure  56  MTI  Location  Error  Model 


The  down  range  error  model  is  be  derived  from  the  la  individual  contributors  as  shown  below: 
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cosE 


Figure  5Z  MTI  Down  Range  Error  Model 

The  cross  range  error  model  can  be  derived  from  the  1(T  individual  contributors  as  shown  below: 


Figure  58  MTI  Cross  Range  Error  Model 


5.2.2  Data  Analysis 

The  1g  down  range  and  cross  range  errors  can  be  derived  from  a  theoretical  model  as  described  in  the 
previous  paragraph  and  from  flight  data  taken  under  controlled  conditions. 
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5.2.2. 1  Location  Error  Budget 

From  the  allocated  location  error  budget,  target  CEP  is  derived  as  a  fimction  of  range  and  angle,  and  is 
used  as  the  basis  of  location  accuracy  measurement.  The  following  diagram  illustrates  the  CEP  curves 
for  a  60°  scan  angle. 

CEP  Approximation 


1  -Sigma  Xr 
- 1 -Sigma  Dr 

-  ■  -  -  CEP 

X  Target 


Range  (Km) 


Figure  St  Theoretical  Location  Accuracy 

Analysis  of  controlled  SLPV  flight  data  provides  the  best  insight  into  the  actual  target  location  errors. 
Controlled  test  conditions  at  variable  range  and  angle  combinations  yield  an  approximate  CEP  model  as 
a  function  of  range  and  angle  fium  which  the  la  down  range  and  cross  range  errors  may  be 
decorrelated.  The  following  diagram  illustrates  the  CEP  curves  for  a  60°  scan  angle. 


CEP  Approximation 
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Figure  510  Location  Accuracy  from  SLPV  Flight  Data 

Further  analysis  of  this  data  shows  that  there  are  four  variable  statistics  which  contribute  to  this  CEP 
approximation; 

•  a  location  error  bias. 
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•  a  random  Gaussian  distribution  about  the  mean, 

•  a  random  exponential  distribution  extending  beyond  the  tails  of  the  Gaussian  distribution  (cross 
range  only), 

•  and  a  uniform  random  distribution  extending  beyond  the  tails  of  the  Gaussian  distribution  (down 
range  only). 

Each  of  these  effects  can  be  seen  in  the  following  diagrams. 


Live  X-Rng  Error  -  TP004 


Cross  Range  Error 


Figure  3.1  Distribution  of  Errors  from  Flight  Data 

JADS  simulation  routines  have  been  successfully  executed  against  SLPV  test  points,  showing  positive 
results: 


Figure  32  Distribution  of  Errors  from  JADS  Simulation 
5.2.2.2  Determination  of  Target  Position 
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Once  the  down  range  and  cross  range  errors  have  been  established  for  a  given  range  and  angle 
combination,  these  statistics  must  be  applied  randomly  to  determine  the  reported  target  location. 
Analysis  of  flight  data  indicates  that  location  errors  consist  of  a  variable  bias,  a  Gaussian  distribution 
about  the  mean,  and  an  exponential/uniform  distribution  extending  beyond  the  Gaussian  tails. 

To  avoid  a  simulation-like  appearance,  each  of  these  characteristics  must  be  modeled  in  the  JADS 
simulation.  This  is  accomplished  by  first  forming  the  fundamental  CEP  ellipse  using  the  theoretical  la 
down  range  and  cross  range  errors  for  that  range  and  angle  condition  (as  derived  from  flight  data 
analysis). 

•  Location  Bias;  A  phasor  is  used  to  model  tire  location  error  bias  by  slowly  moving  the  center  of 
the  error  distribution  inside  the  CEP  ellipse.  Through  observation  of  the  SLPV  flight  data,  the 
magnitude  of  the  phasor  is  approximately  one  fourth  of  the  la  value.  The  phasor  is  incremented 
each  dwell  so  that  all  targets  within  tire  current  dwell  have  the  same  bias.  The  phasor’s  rotation 
rate  varies  randomly  per  revisit  to  the  RSR. 

•  Gaussian  Distribution:  Further  reduction  of  flight  data  shows  that  95%  of  the  targets  are 
Gaussian  distributed  in  the  down  range  component  and  80%  of  the  targets  are  Gaussian 
distributed  in  cross  range  component.  A  uniform  random  number  determines  if  the  target  is 
Gaussian  according  to  these  percentages.  If  the  target  is  Gaussian  distributed,  then  a  Gaussian 
deviate  is  formed  and  applied  to  the  computed  la  value  for  that  target. 

•  Exponential  Distribution  (Cross  Range):  If  a  target  is  selected  to  be  exponential,  then  an 
exponential  distribution  is  applied  in  the  region  extending  beyond  1.5  sigma  (uniformly  positive 
and  negative),  so  that  it  dove  tails  with  the  Gaussian  distributed  targets. 

•  Uniform  Distribution  (Down  Range):  If  a  target  is  selected  to  be  uniform,  then  a  uniform 
distribution  is  applied  in  the  region  extending  beyond  3.0  sigma  (uniformly  positive  and 
negative),  so  that  it  dove  tails  with  the  Gaussian  distributed  targets. 

Once  the  magnitude  of  the  target’s  down  range  (Ear)  and  cross  range  (Exr)  error  has  been  established, 
the  true  TCS  position  (T)  of  the  target  is  modified  as  follows  along  the  radar  line  of  si^t  (T-P): 

Az  =  Tan-'[(Ty-Py)/(T,-Px)] 

P  =  P+  [D]*[E]  [D]=  [Cos(Az)  -Sin(Az) ]  [E]  =  [Ear] 

[  Sin(Az)  Cos(A7)  ]  [  Exr  ] 

5.3  Application  of  MTI  Radial  Velocity  Statistics 

This  section  is  intended  to  detail  the  algorithms  and  techniques  which  were  utilized  to  implement  the 
Moving  Target  Indicator  (MTI)  radial  velocity  accuracy  statistics  for  the  Joint  Advanced  Distributed 
Simulation  (JADS)  environment  on  the  Joint  STARS  platform. 

Radial  velocity  is  measured  by  the  Joint  STARS  radar  using  a  velocity  decode  algorithm  based  on  an 
“M”  out  of  “N”  coherent  processing  interval  (CPI)  scheme.  Each  CPI  uses  a  different  pulse  repetition 
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frequency  (PRF)  designed  such  that  Doppler  blinds  and  foldovers  can  be  mitigated  with  detection  by 
other  PRFs.  The  radar  also  reports  a  radial  velocity  quality  flag  indicating  fliat  the  radar  has  a  high  or 
low  confidence  in  the  accuracy  of  the  reported  radial  velocity.  The  quahty  flag  is  based  on  the  number 
of  CPIs  used  to  detect  the  target  (“M”). 

5.3.1  Data  Analysis 

Radial  velocity  quality  and  error  statistics  have  been  derived  from  data  collected  under  controlled 
conditions  during  SLPV  flight  tests.  Analysis  of  controlled  SLPV  flight  data  provides  the  best  insight 
into  the  actual  target  radial  velocity  errors  fliat  can  be  modeled  for  the  JADS  simulation. 

5.3. 1.1  Radial  Velocity  Error 

Controlled  test  conditions  at  variable  range  and  angle  combinations  show  that  the  reported  radial 
velocity  contains  an  error  distribution  which  is  independent  of  range  and  angle  test  conditions.  The  data 
indicates  that  93%  of  the  reported  targets  form  a  Gaussian  distribution  about  a  mean  generally  shown  to 
be  0.  The  remaining  7%  of  the  targets  form  a  uniform  distribution  beyond  2.5o.  The  uniform 
distribution  appears  to  have  two  levels,  where  approximately  80%  of  the  uniformly  distributed  velocity 
errors  (0.8*7%=5.6%  of  all  detected  targets)  lie  within  15a.  The  wild  points  (  7-5.6=1.4%  of  all 
detected  targets)  consistently  appear  in  each  controlled  test  point.  Figure  5.13  illustrates  the  radial 
velocity  error  profile  from  SLPV  flight  049  fiom  which  the  JADS  simulation  was  derived.  The 
corresponding  profile  for  the  JADS  simulation  results  is  exhibited  in  Figure  5.14. 


Live  Radial  Velocity  Error  -  F3-049 


Radial  Velocity  Error  (cm/s) 


Figure  5L3  Distribution  of  Radial  Velocity  Errors  From  Flight  Data 
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Sim  Radial  Velocity  Error  -  F3-049 


Figure  Distribution  of  Radial  Velocity  Errors  From  JADS  Simulation 
5.3. 1.2  Radial  Velocity  Quality 

Analysis  of  the  radial  velocity  quality  flag  shows  that  the  reported  radial  velocity  quality  is  highly 
correlated  with  the  probabihty  of  detection  (P<i)  for  each  of  the  test  points.  This  seems  logical  since  Pd  is 
also  based  on  the  “M”  out  of  “N”  CPI  detection  scheme.  Therefore  the  radial  velocity  quality  flag 
should  be  randomly  selected  based  on  the  target’s  Pd.  The  radial  velocity  error  profile  for  good  quality 
targets  is  marginally  better  than  that  of  poor  quahty  targets. 


Radial  Velocity  Error  (cm/s) 


Figure  SL5  Distribution  of  Radial  Velocity  Errors  for  Good  and  Bad  Quality  Target 
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6.  JADS  Communications  Connections  At  Northrop  Grumman  Integrated 
Test  Facility  (ITF) 

JADS  is  being  developed  in  multiple  phases.  The  general  concept  of  operation  for  Phase  1  of  the  Joint 
STARS  JADS  project  has  been  as  follows: 

•  The  JADS  system  was  developed  in  the  lab  environment  on  the  Alpha  600’s  workstations 
These  computers  receive  DIS  virtual  targets  PDUs  via  a  T1  line  from  White  Sands  Missile 
Range  (WSMR)  via  Kirtland  AFB  which  is  connected  to  the  laboratory  setup  for  data 
monitoring  purposes.  An  SGI  workstation  is  used  to  log  the  PDU  data  files  which  are  received 
over  the  DIS  WAN  (Tl). 

•  The  target/war  simulation,  JANUS  operates  at  the  White  Sands  Missile  Range  (WSMR), 
generating  virtual  targets  and  issuing  Protocol  Data  Units  (PDUs)  on  the  Distributed  Interactive 
Simulation  (DIS)  network. 

•  The  Radar  Processor  Simulation  Integrator  (RPSI),  which  executes  on  the  Alpha  600’s 
computers,  receives  the  virtual  target  information,  via  entity  state  PDUs  which  are  received  from 
the  DIS  network,  or  replayed  from  the  SGI  workstation.  The  ALPHA  600s  are  cormected  to 
an  Ethernet  LAN  which  in  turn  interfaces  with  the  T-1  line  via  an  IDNX  and  an  KIV-7 
encryption  device.  The  RPSI  supplies  virtual  target  radar  reports  combined  with  the  live  target 
radar  reports  (MTI  and  SAR  reports)  to  operator  work  stations  and  to  a  SCDL  emulation. 

•  At  present  for  JADS,  a  single  Tl  commuiucations  service  line  is  connected  into  the  Northrop 
Grumman  Integration  and  Test  Facihty  (TTF)  building  222.  This  fine  provides  for  the  incoming 
simulation  data  (PDUs )  and  outgoing  messages  to  and  from  the  TCAC  at  Kirtland  AFB.  A 
second  T-1  service  (currently  not  in  service)  was  utilized  for  transmitting  SCDL  data  (MTI  and 
SAR  Target  reports)  to,  and  receiving  Radar  Service  Requests  (RSR)  from  an  Army  ground 
station  module,  (GSM  or  a  replica,  GSMR),  at  Motorola  in  Phoetux,  Arizona.  A  third  T-1 
service  (yet  to  be  connected)  will  be  cormected  during  the  next  phase,  to  establish  a  link  to  a 
GSMR  at  Fort  Hood 

•  Connections  were  established  so  that  the  PDU  files  in  the  SGI  (located  on  the  second  floor  of 
the  ITF,  in  room  209)  can  be  routed  to  the  ITF  Classified  LAN  which  cormects  to  the 
Northrop  Grumman  Operations  and  Control  Test  Laboratory  (OCTL)  which  is  located  on  the 
fourth  floor  of  the  ITF.  The  JSTARS  Prime  Mission  Equipment  (PME)  is  located  in  the  OCTL 
and  normally  is  connected  to  this  LAN.  The  ALPHA  600  computers  can  also  be  cormected  to 
this  LAN. 

•  Cormections  also  were  established  for  a  third  LAN,  so  that  the  ALPHA  600  computers  can  be 
cormected  to  two  of  the  operator  workstations  (OWS)  of  the  JSTARS  PME  in  the  OCTL. 
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These  wiring  connections  internal  to  the  Northrop  Grumman  ITF  are  shown  in  Figure  6.1.  Figure  6.3 
illustrates  the  connections  between  and  major  equipment  in  the  Northrop  Grumman  ITF  and  in  the  other 
DIS  facilities  utilized  by  the  JADS  JTF. 

6.1  Secure  Voice  Communications 

A  direct  secure  voice  communication  connection  via  T1  lines  from  the  Northrop  Grumman  ITF  in 
Melbourne,  FI  to  the  TCAC  in  Albuquerque,  NM,  enables  continued  direct  communication  between 
ITF  and  the  TCAC  during  the  execution  of  planned  JADS  tests. 

The  direct  telephone  voice  communication  link  utilizes  one  of  the  24  sub  channels  from  one  of  the 
secure  T1  lines  which  connect  between  the  ITF  and  the  faciUties  at  Albuquerque  NM.  A  circuit  card  ( 
a  Quad  Analog  Voice  Card)  was  installed  in  the  existing  IDNX..  (see  Figure  6.1).  The  IDNX  functions 
as  a  demultiplexer  and  the  circuit  card  enables  the  use  of  one  sub  channel  from  the  T1  channels,  for  use 
as  the  voice  phone  channel. 

An  electronic  Voice  Signal  Converter  provides  for  voice  transmission  over  the  multiplexed  digital  data 
link. 
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Figure  61 JADS  Communications  Connections  In  Northrop  Grumman  ITF 
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6.2  Equipment  Description  and  Utilization 

The  following  describes  the  equipment  and  its  use: 

The  Alpha  600  workstations  are  known  as  “JADSOl”  and  “JADS02”,  Each  is  equipped  with  a  single 
333-Mhz  CPU.  One  is  equipped  with  512  of  RAM,  the  otiber  with  1  GByte  of  RAM.  The  operating 
system  is  DEC  OpenVMS  Version  7.0.  The  JADS  RPSl  software  executes  in  this  equipment. 

The  SGI  Workstation,  known  as  “grumman”,  functions  as  a  DIS  PDU  logger/replayer  and  as  a  Video 
Teleconferencing  Device  (VTC). 

The  two  Verilink  CSU/DSU  devices  function  as  the  Channel  Service  Units  /  Data  Service  Units  for 
converting  the  T1  line  signals  for  input  into  the  KIV-7  HS  crypto  devices. 

The  two  Alhed  Signal  BQV-7  HS  Crypto  devices  function  as  the  encrypters/decrypters. 

The  Network  Equipment  Technologies  IDNX/Micro  20  device  (Part  number  01-53405)  functions  as 
the  multiplexer.  The  IDNX  sphts  the  signal  coming  in  from  the  Northrop  Grumman  JADS  system,  using 
the  CISCO  7000  software,  and  routes  the  outgoing  messages  according  to  their  addressed  destinations 
which  are: 

•  The  SCDL  which  interfaces  with  the  Motorola  GSMR.  and, 

•  The  DIS  interface  to  the  JANUS  scenario  generator  at  WSMR,  NM  via  the  TCAC  at  Kirtland 
AFB,  Albuquerque,  NM. 


The  Voice  Signaling  Converter  is  a  RAD  Data  Systems  device  (  290100000G)  which  enables 
connection  of  voice  equipment  to  data  communications  equipment,  and  provides  voice  transmission 
over  a  multiplexed  data  Unk. 

6.3  Connections  to  Provide  for  Developmental  Testing  of  the  TADIL  J  U  Tracker  Algorithms 

Additional  connections  were  established  to  accommodate  the  TADIL-J  Upgrade  (TJU)  program 
software  developmental  testing  of  new  target  tracking  algorithms  using  the  JADS  RPSI.  The  TJU 
connections  are  shown  in  Figure  6.2.  These  connections  permit  the  OCTL  trellis  and  associated 
workstations  to  be  connected  to  the  JADS  scenario  PDU  playback  assets  (the  SGI  workstation) ,  to 
support  the  algorithm  tests.  They  also  permit  an  Alpha  Station  500  workstation  to  be  connected  to  the 
JADS  scenario  playback  assets.  This  workstation  is  utilized  for  TJU  tracker  algorithm  development  and 
test.  In  addition  the  JSTARS  PME  computer  systems  in  the  OCTL  trellis  can  be  connected  to  an 
alternate,  isolated  network  segment  which  was  installed  for  the  JADS  program.  The  TJU  connections 
provide  the  capabihty  to  connect  the  entire  trelUs  OWS  LAN  to  the  JADS  isolated  LAN  (“D3”) 
segment.  The  JADS  systems  will  not  be  connected  to  their  external  T1  links  when  the  OCTL  treUis 
mission  computers  are  attached.  This  is  protected  by  the  manner  in  which  the  alternate  LAN’s  are 
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connected  (i.e.  only  the  isolated  JADS  segment  are  available  to  the  trelHs;  the  external  segment  are 
accessible  to  the  JADS  computers  when  fliey  are  off-line  from  the  isolated  LAN  segment). 

These  TJU  systems  can  be  connected  to  each  other  and  to  other  computer  assets  by  means  of  the 
isolated  JADS  “D3”  Ethernet  network  segment  in  the  ITF.  Trellis  assets  may  be  connected  to  the 
laboratory  OWS  LAN  or  to  the  isolated  JADS  LAN  segment  via  the  OCTL  patch  panel  area  housed 
in  the  STL.  The  ALPHA  500  workstation  has  an  alternate  patch  block  installed  for  the  alternate, 
isolated  LAN. 


Data  link  protection  is  provided  by  the  security  approved  network  supported  by  the  IS  department  and 
DSSD.  Isolation  from  the  external  JADS  T1  link  is  provided  by  a  IS/Networks-supplied  patch  panel  on 
the  second  floor  in  the  JADS  asset  area.  These  connections  are  maintained  by  the  NG  IS  department 
and  DSSD.  IS/Networks  provide  and  maintam  the  network  hubs  and  supply  data  necessary  for  security 
approval  of  network  assets. 
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Figure  ffl  JADS  Connections  for  TADIL  J  U  (TJU^evelopmental  Tests 
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Figure  ®  Communications  Diagram  for  JADS/VSTARS 
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1.  Introduction 


The  Joint  Advanced  Distributed  Simulation  End-to-End  (IADS  ETE)  team  has  funded  Lockheed 
Martin  TDS  Arizona  to  develop  a  Synthetic-Aperture  Radar  (SAR)  simulation  that  emulates  the  Joint 
STARS  SAR  operation.  This  simulation  system  is  referred  to  as  the  Advanced  Radar  Imaging 
Emulation  System  (ARIES)  and  is  operationally  embedded  into  Northrop  Gnimman’s  Radar  Processor 
Simulation  Integrator  (RPSI).  The  RPSI  integrates  the  Distributed  Interactive  Simulation  (DIS) 
environment  with  a  simulated  SAR  and  moving-target  indication  (MTI)  capabUity.  This  integrated 
system  is  known  as  tiie  Virtual  Surveillance  Target  Attack  Radar  System  (VSTARS). 

The  development  of  the  ARIES  has  been  designed  as  a  two-phase  effort.  Phase  I  of  the  ARIES 
program  identified  the  system  requirements,  determined  software  interfaces  between  tiie  RPSI  and 
ARIES,  and  identified  the  process  by  which  to  integrate  real-world  topographical  and  feature 
databases.  This  design  was  presented  to  the  government  at  the  end  of  Phase  I  and  accepted  at  a  formal 
Acceptance  Design  Review.  Phase  n  is  defined  as  the  implementation  and  testing  of  Phase  I  design. 
This  final  report  covers  our  approach  and  performance  of  Phase  H. 

2.  Technical  Overview 

The  ARIES  project  utilized  a  time-phased  development  approach  creating  three  distinct  software  builds. 
Each  build  provided  increased  functionahty  and  verified  that  requirements  were  met.  This  incremental 
development  approach  was  designed  to  minimize  the  integration  and  performance  risk  associated  with 
emulating  a  JSTARS  SAR  by  providing  feedback  from  the  customer  in  regards  to  the  various  stages  of 
the  development. 

The  ARIES  program  is  an  enhancement  to  the  SAR  simulation  capabilities  previously  demonstrated  by 
the  XPATCHES  simulation.  XPATCHES  is  a  non-real  time,  high  fidehty,  multispectral  simulation  tool. 
ARIES  emulates  the  radar  operational  parameters  of  the  JSTARS  SAR  sensor  in  real-time  with  tiie 
added  capability  of  using  real-world  databases  such  as  DTED  and  DEAD. 

The  software  development  was  guided  by  a  prototype  approach  to  determine  algorithmic  results  and 
execution  performance  levels  before  detailed  code  was  written.  As  most  of  the  design  was  graphical 
dependent,  software  development  tools,  such  as  PV-Wave,  were  used  to  assess  the  validity  of 
algorithm  development.  This  instituted  an  effective  methodology  for  data  analysis,  image  processing, 
and  the  use  of  tabular  manipulation  for  record-based  data  used  in  real-time  application  and  optimization. 

2.1  Technical  Approach 

As  mentioned  previously,  ARIES  was  developed  in  three  successive  builds.  The  following  sections 
define  the  builds  and  the  functionality  attained  with  each  one. 
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2.1.1  Build  1 


Build  1  demonstrated  the  functionality  of  the  shaded  modules  and  soUd  line  interfaces  in 
Figure  2.1-1. 

Figure  2.1-1  ARIES  system  design  illustrating  modules  associated  with  Build  1. 


The  shaded  modules  and  solid  lines  indicate  the  software  and  interfaces  that  are  functional  with  this 
build. 

The  Off-line  Pre-Processing  Module  converts  the  DTED  and  DFAD  data  to  the  ARIES  database  as 
defined  in  the  Digital  Database  ICD.  This  conversion  work  was  performed  by  the  government  and 
provided  as  GFE.  As  ARIES  is  executed  in  conjunction  with  other  simulations  in  the  RPSI,  a  common 
database  origin  must  be  matched  for  registry  of  images.  This  conversion  process  converts  the 
latitude/longitude  coordinates  of  the  DMA  databases  into  the  agreed  upon  “topocentric”  coordinates  of 
the  simulation  arena.  No  other  database  manipulation  is  performed.  The  ARIES  database  contains  a 
512kmx512km  “pla3ang  field”  and  is  stored  off-line  on  a  tape. 

The  Internal  Database  Module  consists  of  the  intialization  software  which  handles  the  loading  of  the 
databases  into  memory  consistent  with  an  operator  chosen  subset  of  the  entire  512  km  x  5 12  km  arena. 
Upon  system  startup,  the  initiali2ation  software  will  execute  an  initialization  file  which  contains  the 
Ground  Reference  Coverage  Area  (GRCA)  parameters  (location,  width,  depth),  and  season, 
atmosphere,  and  wind  conditions.  These  parameters  are  specific  to  the  execution  of  the  simulations  up 
to  the  time  they  are  changed  (reinitialized).  These  parameters  are  changed  through  an  operator  interface 
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to  the  initialization  file  and  may  be  modified  at  any  time  to  meet  the  mission  requirements  as  needed. 
Based  on  the  GRCA  parameters  set  by  the  operator,  the  initialization  software  retrieves  the  elevation 
and  feature  information  fi:om  the  external  tape  and  loads  it  into  memory  for  quick  retrieval  during 
executions. 

The  Real-Time  Processing  module  includes  an  RPSI  interface  and  the  software  image  generation 
modules,  CSCI-1  Ground  Truth  and  CSCI-2  SAR  Image  Generation.  The  RPSI  interface  provides  all 
operational  and  navigational  parameters  for  SAR  processing  and,  in  turn,  accepts  a  SAR  image  upon 
completion.  This  interface  was  tested  during  Build  1  and  can  pass  and  accept  all  radar  parameters  and 
images  as  specified  in  the  RPSI  ICD.  CSCI-1  directly  interfaces  with  the  RPSI,  and  upon  receiving  a 
SAR  image  request,  it  accepts  and  parses  the  operational  and  navigational  data  received.  This  message 
contains  the  Area  of  Interest  (AOI),  sensor  parameters,  and  target  type,  state,  orientation,  and  location. 
To  test  CSCl-1  fimctionality  during  Build  1,  a  routine  was  invoked  that  displayed  targets  by  placing  a 
symbol  in  their  respective  locations  in  an  image.  This  image  did  not  contain  any  SAR  information  at  that 
time,  and  was  used  for  target  placement  and  I/O  verification.  The  image  was  then  passed  to  CSCI-2 
which,  in  turn,  sent  the  image  back  to  the  RPSI,  verifying  the  interface  functionality  between  the  RPSI 
and  CSCI-2. 

Build  1  consisted  of  the  delivery  of  the  first  draft  elevation  and  feature  database  modifications  from 
WSMR,  the  initialization  software,  and  all  software  necessary  to  integrate  and  test  system  and  software 
interfaces. 

2.1.2  Build  2 

Build  2  demonstrated  the  functionality  of  the  shaded  modules  and  solid  line  interfaces  in 
Figure  2.1-2. 

Build  2  provided  a  preliminary  SAR  output  image.  The  simulation  software  generates  an  image  that 
contained  a  subset  of  the  required  features  and  targets.  The  SAR  image  is  based  on  feature  data 
contained  in  the  GRCA.  Targets,  previously  designated  by  symbols  in  Build  1,  have  their  SAR 
signatures  inserted  into  the  imagery.  Build  2  utilizes  portions  of  CSCI-1  Ground  Tmth,  with  tire  added 
capability  from  CSCI-2  SAR  Image  Generation,  to  produce  the  preliminary  SAR  output  imageBuild  2 
utilizes  the  development  of  support  libraries,  required  for  ARES  SAR  image  emulation,  as  identified  in 
Figure  2.1-2.  The  ARES  library  contains  the  SAR  representation  of  selected  terrain  textures, 
manmade  and  cultural  features,  target  signatures,  and  tabulated  mathematical  functions.  These  allows 
efficient  look-up  of  tabulated  data  rather  than  time-consuming  calculations  where  real-time  performance 
is  mandatory.  Terrain  textures  include  features  such  as  gravel,  sand,  and  rocky  flats.  Manmade  features 
include  buildings,  oil  storage  tanks,  and  power  lines.  Terrain  textures  and  features  are  based  on  sample 
JSTARS  imagery,  when  available  and  are  used  in  the  testing  activity  at  the  program  end.  XPATCH 
Target  signatures  were  not  deemed  necessary  due  to  the  resolution  of  the  JSTARS  sensor.  Targets 
were  extracted  from  real  imagery  and  based  on  their  spatial  distribution,  were  recreated  to  emulate  real 
signatures  for  use  in  ARES.  Function  libraries  are  used  for  mathematical  efficiency  and  include  tabular 
functions  and  precomputed  weighting  factors  used  in  image  processing. 
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Figure  2.1-2  ARIES  system  design  illustrating  Build  2  completed  modules. 

All  interfaces  between  modules  are  working  and  the  first  subset  of  the  ARIES  library  has  been  released. 

CSCI-1  generates  a  ground  truth  for  the  SAR  scene.  This  ground  truth  is  a  point  map  for  locating 
features  and  targets  in  the  image,  and  contains  all  elevation  data  necessary  for  the  3-D  processing 
effects  that  are  performed  in  CSCI-2.  In  this  build,  CSCI-1  loads  the  GRCA  elevation  and  feature 
data  and  rotates  it  into  the  Ime-of-sight.  The  elevation  data,  previously  stored  at  low  resolution,  will  be 
upsampled  to  the  sensor  resolution.  All  the  CSCI-1  processed  data  is  stored  in  a  stmcture  referred  to 
as  a  point  map  and  is  passed  to  CSCI-2  for  SAR  processing. 

CSCI-2  accepts  the  point  map  generated  in  CSCI-1  and  performs  a  3-D  to  2-D  projection.  The  height 
parameter  on  the  3-D  topographical  and  feature  data  is  used  to  generate  obscuration,  shadows,  and 
surface  gain  reflectivity.  This  parameter  calculates  edge  reflectivity  effects  due  to  the  dihedral  geometry 
created  by  two  adjacent  surfaces  of  differing  heights.  The  gain  is  a  function  of  surface  geometry  and 
material  parameter.  Once  the  gain  and  shadow  map  is  complete,  the  SAR  targets,  textures,  and  features 
are  inserted  into  the  image.  The  textures  and  features  are  modulated  by  the  gain  map,  thereby  ensuring 
that  features  are  not  inserted  where  there  is  obscuration  or  shadowing.  Moving  targets  are  inserted  last 
in  the  image,  as  their  velocity  affects  location  and  signature.  The  combined  gain  map  and  features 
produce  an  image  referred  to  here  as  a  “raw”  SAR  image,  ie.,  this  image  has  had  only  geometric 
processing  performed  on  it.  The  final  step  to  simulation  is  applying  image  processing  on  flie  raw  image. 
The  insertion  of  features  and  textures  requires  the  blending  of  edges,  seams,  and  boundaries.  This 
process  requires  a  filtering  procedure  to  spatially  correlate  each  feature  to  another. 
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2.1.3  Build  3 


Build  3  demonstrated  the  functionality  of  the  shaded  modules  and  solid  line  interfaces  in 
Figure  2.1-3. 


Figure  2.1-3.  ARIES  system  design  illustrating  completed  modules. 

The  complete  set  of  features  have  been  integrated  into  the  library  and  CSCI-1  and  CSCI-2  are  Mly 
functional  having  complete  image  processing  capability. 

Build  3  produces  the  complete  ARIES  SAR  image  generation  capability.  Build  3  integrates  the 
completed  CSCI-1  and  CSCI-2,  and  the  full  set  of  features  supported  by  ARIES.  Acceptance  testing 
at  the  completion  of  this  effort  was  conducted  to  verify  conformance  with  the  Software  Requirement 
Specifications  and  the  customer  submitted  Acceptance  Test  Procedure.  Results  of  those  tests  are  in  the 
Acceptance  Test  Section  5.0. 

3.  Software  Design 

3.1  Software  Architecture 
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As  ARIES  was  implemented  in  a  prototype  development  environment,  the  design  was  revised  as 
implementation  progressed.  The  new  ARIES  software  architecture  is  best  represented  as  four  distinct 
modules:  Initialization,  Ground  Tmth,  SAR  Generation,  and  Support.  Initialization  and  Ground  Trath 
comprise  CSCI-1  and  SAR  Generation  and  Support  comprise  CSCI-2.  Table  3.1-1  represents  the 
software  structure,  module  file  names,  and  functional  description.  Execution  begins  when  the 
Initialization  module  is  called  to  setup  the  memory  stmctures  required  for  execution.  The  Ground  Truth 
module  provides  the  entry  point  for  the  real-time  image  generation  software.  The  SAR  Generation 
module  is  invoked  by  the  Ground  Tmth  module  which  then  returns  the  image  and  status  to  the  caUing 
routine.  Execution  within  the  CSCI,  through  the  CSUs,  is  basically  a  linear  procedure  as  listed  in  Table 
3.1-1.  Each  CSCI  main  module  contains  initialization  entry  points  called  by  flie  Initialization  module. 

Table  3.1-1  Software  Structure,  Module  File  Names,  and  Functional  Descriptions 


CSCI  /  CSC  /  csu 

Module  Name 

Description 

Initialization  (CSCI-1) 

init_main 

Upper  level  control.  Read  elevation  data,  crop  to 
GRCA. 

Read  .INI 

init_ini 

Read  aries.ini  file  and  parse  parameters. 

Read  Features 

init_feature 

Read  feature  data  file  and  crop  to  GRCA. 

Build  Search  Tree 

init__tree 

Create  empty  search  tree  stmcture. 

Merge  Features  and  Tree 

initjmerge 

Parse  features  in  to  search  tree. 

Ground  Truth  (CSCI-1) 

gnid_main 

Initialize  stmctures.  Upper  level  control  flow. 

Setup  Calculations 

gmd_setup 

Extract  RPSI  data  and  initialize  parameters. 

Transform  Targets 

gmd_targets 

Transform  target  data  to  AOI  coordinate  system. 

Extract  AOI  Features 

gmd_feature 

Extract  feature  data  that  is  contained  within  the  AOI. 

Process  Elevation  Data 

gmd„elev 

Extract  and  interpolate  AOI  elevation  data. 

Create  Ground  Truth 

gmd_truth 

Draw  AOI  features  into  point  map. 

Draw  Point  &  Linear 
Features 

gmdjine 

Draw  point  and  linear  feature  types. 

Draw  Area  Features 

gmd„area 

Draw  area  feature  types. 

SAR  Generation  (CSCI-2) 

sargen_main 

Read  library.  Upper  level  control  flow. 

Elevation  Textures 

sargen_fractal 

Apply  dune  and  fractal  elevation  textures. 

Shadow  Projection 

sargen_shadow 

Project  shadows  onto  shadow  mask. 

Reflective  Gain 

sargen_gain 

Compute  gain  returns  for  each  point. 

Texture  Application 

sargen_texture 

Apply  textures  to  image  combined  with  gain. 

Target  Insertion 

sargen_targets 

Insert  target  chips  and  smears  into  image. 

Image  Processing 

sargen_image 

Apply  filtering  algorithms. 

Noise  Processing 

sargen_noise 

Apply  noise  and  shadow  mask. 

Image  Output 

sargen_output 

Convert  complex  image  to  pixel  ou^ut. 

Support  (CSCI-2) 

none 

n/a 

Common  Functions 

supp_funcs 

Common  support  functions. 

Data  Logging 

suppjogging 

Debug  data  logging  utilities. 

Complex  Numbers 

supp_complex 

Complex  number  operations  for  C. 
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3.2  Supported  Features 

Table  3.2-1  lists  all  features  supported  by  ARIES  and  how  those  features  are  implemented. 

Table  3.2-1  Features  Supported  by  ARIES 


Description 

FID 

Type 

Ground  Truth  Implementation 

SAR  Image 
Implementation 

Dual  hiways  with  medians 

250 

Linear 

Dual  Line,  width,  elevation  of  -0.01m 

Dark 

All  Weather,  Hard  Surface 
highway 

251,252, 255 

Linear 

Line,  width,  elevation  of  -0.01m 

Dark 

Fair  Weather,  loose  or  light 
surface  road 

253 

Linear 

Line,  width,  elevation  of  -0.01m 

Dark 

Cart  track,  trail 

254 

Linear 

Line,  width,  elevation  of  -0.01m 

Dark 

Airport  Runway  and  Taxiways 

706 

Linear 

Line,  width,  elevation  of  -0.01m 

Dark 

Storage  Tanks  -  General 

801 

Point 

Single  Point 

Chip  w/o  profile 

Soil 

902 

Area 

Fill 

Smooth 

Sand  dunes 

907 

Area 

Fill  with  dune  elevation  texture 

Smooth 

Smooth,  solid  rock 

Area 

Fill 

Fine 

Rocky,  rough  surface 

912 

Area 

Course 

Dry  Lake 

913 

Area 

Fill 

Smooth 

Cleared  ways 

916 

Linear 

Line,  width,  elevation  of  -0.01m 

Smooth 

Walls 

922 

Linear 

Line,  width,  edge,  fill,  elevation 

Dark/Smooth 

Fresh  water 

940 

Linear/Area 

Line+width  or  Area,  elevation  of  - 
0.2m 

Dark 

Canal 

947 

Line+width,  elevation 

Dark 

Non-perennial  stream 

945 

Linear/Area 

Line+width  or  Area,  elevation 

Dark 

Depot 

778 

Area 

Fill 

Smooth 

Packed  sand  &  gravel 

906 

Area 

Fill 

Fine 

Loose  Sand 

917 

Area 

Fill 

Smooth 

Dry  Depression 

918 

Area 

Fill 

Smooth 

Wadi 

919 

Linear/Area 

Line+width  or  Area,  elevation 

Smooth 

Salt  Marsh 

908 

Area 

Fill 

Dark 

Salt  Flats 

934 

Area 

Fill 

Fine 

Flood  Plain 

914 

Area 

Fill 

Dark 

Power  Tmsmssn  Twrs 

540 

Single  Point,  elevation  (lines 
between) 

Chip  w/o  profile 

Electric  Power  Lines 

541-544 

Line,  one  point  wide 

Impulse 

Communications  Twrs 

501 

Point 

Single  Point,  elevation 

Chip  w/o  profile 

Date  Palm 

957 

Point 

Single  Point 

Chip  w/  profile 

Revetment  -  Soil/sand/dirt 

981 

Linear 

Line,  width,  elevation 

Fine 

Levee 

921 

Linear 

Line,  width,  elevation 

Fine 

Berms 

982 

Linear 

Line,  width,  elevation 

Fine 

Escarpment 

924 

Linear 

Line,  width,  elevation 

Smooth 

Table  3.2-1  Features  Supported  by  ARIES  (cont.) 

E-13 


Description 

FID 

Type 

Ground  Truth  Implementation 

SAR  Image 
Implementation 

Chain  link  Fence 

927 

Linear 

Line,  one  point  wide 

Impulse 

Barbed  wire  Fence 

983 

Linear 

Line,  one  point  wide 

Concertina  Fence 

984 

Linear 

Line,  one  point  wide 

Irrigated  Field 

958 

Area 

Fill 

Dark 

Ditch 

985 

Linear 

Line,  width,  elevation 

Fine 

Trench 

986 

Linear 

Line,  width,  elevation 

Fine 

Oil  Wells 

103,474 

Point 

Single  Point,  elevation 

Chip  w/o  profile 

Palm  Tree 

551 

Point 

Single  Point 

Chip  w/  profile 

All  Buildings 

104, 120, 130, 
138, 160, 180, 
181,  182, 184, 
222, 290,301, 
324,401,420, 
430,451,530, 
601,604,620, 
630, 650, 680, 
701, 770,  822, 
824, 861 

Point 

Building,  edge,  fill,  elevation 

Dark/Smooth 

Pipelines 

281 

Linear 

Line,  one  point  wide.  Orientation 

Impulse 

Railroad  tracks 

206 

Linear 

Line,  one  point  wide.  Orientation 

Impulse 

Quarries 

102 

Area 

Fill 

Course 

Bridges 

260 

Point 

Length,  Width,  fill.  Elevation  of 
comer 

Impulse 

3.3  Supported  Targets 


The  following  list  represents  the  targets  supported  by  ARIES  for  VSTARS 

ARMORED  PERSONNEL  CARRIERS  -  WHEELED 

BRDM-1 

BRDM-2 

BTR-60P 

ARMORED  PERSONNEL  CARRIERS  -  TRACKED 

BMP-2 

BMP-1 

MTLB 
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TRUCKS 


M-35 

HMMWV 

M-49A2C 

UAZ  Jeep 

AAGUNS 

ZSU-234 

SA-13 

Long  Track  Radar 
TOWED  GUNS 
D-30 
T-12 

MULTIPLE  ROCKET  LAUNCHERS 

BM-21 

BM-22 

TANKS 

T-54 

T-55-T-72 

SELF  PROPELLED  GUNS 

251 

252 

HELICOPTERS 
MI-8  HIP 
MI-24  HIND 
M-28  HAVOC 
TELS 
SA-6 
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4.  System  Performance 

4.1  Objectives 

4.1.1  Database  Driven 

The  objective  of  the  ARIES  simulation  tool  is  to  model  a  JSTARS  SAR  sensor  in  a  which  the  image 
content  directly  correlates  with  the  real  world,  and  the  operational  and  navigational  parameters 
implemented  in  the  simulation  are  those  of  an  actual  aircraft  during  data  collection.  To  model  the  real 
world,  also  referred  to  here  as  ground  tmth,  a  terrain  database  is  needed  to  describe  the  surface 
topology  and  a  feature  database  is  required  that  describes  the  features  that  lie  within  the  terrain. 

The  databases  that  were  implemented  for  ARIES  were  DMAs  DTED  Level  I  and  DEAD.  The  terrain 
database  has  a  significantly  courser  resolution  than  the  SAR  sensor  as  DTED  Level  I  consists  of  100- 
meter  elevation  posts.  For  a  typical  SAR  image,  this  equates  to  approximately  20  elevation  posts  used 
to  describe  the  ground  in  cross  range  and  40  elevation  posts  used  to  describe  the  ground  in  range. 
Because  as  the  SAR  sensor  has  a  much  finer  resolution,  this  creates  a  major  discrepancy  between  the 
ground  trath  description  and  and  the  amount  of  detail  the  virtual  SAR  needs  to  create  a  realistic  image. 
ARIES  handles  this  problem  by  first  performing  an  interpolation  in  both  directions  using  the  real 
elevation  data  and,  secondly,  overlaying  a  finer  elevation  grid  that  is  representative  of  the  terrain  type  on 
which  the  image  is  being  created.  As  an  example,  a  mountainous  terrain  would  have  a  largely  varying 
elevation  grid  applied  and,  likewise,  a  desert  terrain  would  call  for  a  smoother  and  finer  elevation  grid. 
This  methodology  brought  a  visual  reality  to  the  images  that  was  not  evident  when  just  using  DTED 
alone.  Does  this  accurately  represent  the  real  world  to  the  resolution  of  the  sensor?  -  only  as  a  first 
approximation,  but  no  database  exists  at  this  time  that  does.  Because  no  images  were  provided  of 
Southwest  Asia  at  the  operational  parameters  of  the  VSTARS  system,  the  “look”  of  the  terrain  is  a 
subjective  matter,  largely  based  on  the  imagination  of  the  developer. 

4.1.2Real-Tiine  Processing 

A  requirement  was  placed  on  the  ARIES  simulation  to  produce  an  image  in  real  time  which  is  defined  as 
the  time  for  the  real  sensor  to  collect  and  process  data.  The  real-time  processing  was  to  be  performed 
on  a  DEC  Alpha  600  single  processor  that  has  one  Gigabyte  of  RAM.  Originally  the  display  image  siie 
was  given  by  Nortiirop  Grumman  to  be  1024  pixels  x  5 12  pixels.  This  image  display  was  increased  as 
more  information  was  provided  throughout  the  design  process  to  a  final  image  size  of  1632  x  1024. 
The  image  dimensions  had  grown  by  a  factor  of  four  (we  process  internally  to  a  power  of  two  thus 
creating  a  2048  x  1024  image  ,  then  cropping  to  the  required  1632  x  1024)  but  the  image  generation 
timeline  had  only  increased  by  a  factor  of  1.8  -  acceptable  with  respect  to  the  reqxtirements.  The 
timeline,  had  the  image  size  remained  the  original,  would  have  been  satisfied  with  seconds  to  spare.  The 
real-time  image  generation  issue  guided  the  majority  of  the  ARIES  design.  Much  of  what  could  have 
been  processed  or  generated  during  execution  was  skillftilly  created  ahead  of  time  and  implemented 
using  tabular  data  and  libraries. 
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4.1.3  linage  Quality 


The  performance  of  the  ARIES  system  is  measured  against  the  performance  of  the  real  JSTARS  SAR 
sensor.  It  is  the  objective  of  the  simulation  to  emulate  the  effects  of  a  real  SAR  sensor,  not  that  of  a  real 
processor.  Much  of  the  SAR  effects  that  are  visible  in  radar  images  are  due  to  the  physical  attributes  of 
the  terrain  and  features  that  are  illuminated.  Other  factors  include  the  electromagnetic  scattering 
properties  of  the  features,  the  operational  parameters  of  the  sensor,  the  navigational  parameters  of  the 
aircraft,  and  the  image  processing  techniques  used  to  visually  optomize  the  images.  To  evaluate  all 
these  factors  and  their  effects  on  the  images,  real  imagery  was  requested  from  Northrop  Grumman  that 
would  be  used  as  a  sample  for  development  purposes.  It  was  necessary  to  provide  images  that 
contained  the  same  type  of  operational  and  environmental  conditions  as  would  be  present  in  the 
VSTARS  simulated  scenarios.  The  following  paragraphs  describes  the  images  provided  by  Northrop 
Grumman  and  the  VSTARS  scene  requirements  that  either  did  or  did  not  match  those  of  the  sample 
images. 

The  terrain  used  for  the  VSTARS  is  in  Southwest  Asia,  therefore  it  was  imperative,  as  a  minimum,  that 
the  sample  imagery  provided  by  Northrop  Grumman  be  that  of  desert  terrain.  The  radar  operational 
parameters  used  to  collect  the  data  are  also  of  significance  in  the  example  images,  because  the  terrain 
and  features  varied  dramatically  under  various  depression  angles,  squint  angles,  aperture  times,  and 
ranges.  It  was  for  this  reason  that  Lockheed  Martin  TDS  Arizona  requested  the  complex  data  output  of 
the  real  processor.  This  data  would  have  provided  the  necessary  absolute  values  on  dynamic  range, 
target-to-clutter  ratio,  and  background  noise  levels.  The  complex  data  was  not  provided  and, 
therefore,  the  simulation  development  largely  comprised  analyzing  the  intensity  and  spatial  distribution  of 
byte  scaled,  histogram  equalized  images. 

Most  visual  evaluations  performed  after  final  system  integration  on  the  background  terrain  gave  positive 
feedback.  Most  evaluators  asked  if  the  images  were  simulated  or  real  -  which  proved  to  be  the  best 
compliment  to  the  realism.  Two  evaluators  differed  greatly  on  their  assessment  of  what  was  “wrong” 
with  the  background.  One  evaluator  thought  the  terrain  was  too  sharp  and  thereby  created  too  much 
contrast  in  the  image.  Another  evaluator  thought  that  there  was  not  enough  contrast  and  the 
background  needed  much  larger  hills  and  valleys.  The  conclusion  made  by  Lockheed  Martin  TDS  and 
the  customer  -  without  the  proper  data  supplied  by  Northrop  Grumman  to  support  these  image 
evaluations  and  their  subjective  content,  the  quality  and  realism  are  left  to  the  individual  viewer.  The 
image  quality  was  deemed  acceptable  by  the  customer’s  requirements. 

4.2  Sample  Imagery 

The  following  section  contains  simulated  imagery  that  was  processed  through  the  RPSI  following  the 
final  installation  at  Northrop  Grumman. 
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To  initiate  the  virtual  SAR,  a  Radar  Service  Request  (RSR)  is  obtained  from  an  operator  interface. 
The  area  to  image  is  chosen  by  viewing  the  hyposographic  data  on  the  operator  workstation,  clicking  in 
on  the  earth  coordinates  that  lie  within  the  radar  coverage  area,  and  initiating  an  RSR.  This  interface  is  a 
mock-up  that  the  operator  uses  on  the  aircraft  workstations.  Moving  and  stationary  targets  are 
supported  by  passing  target  information  from  a  DIS  link  through  the  RPSI  and  parsing  it  to  ARIES  via  a 
target  file.  This  file  contains  the  reference  information  required  to  locate  and  process  targets  within  the 
SAR  image.  The  hypsographic  data  is  overlayed  onto  the  images  and  is  evident  by  the  lines  passing 
through  or  outlining  some  of  the  features. 

This  image  represents  several  successive  merged  data  collections.  The  features  present  in  these 
collections  are  a  road  traveling  NW  to  SE  as  well  as  several  rivers  meadeiing  through  the  image.  The 
roads  and  rivers  are  represented  by  the  hypsographic  overlay.  The  lines  and  features  are  slightly  offset 
due  to  Circular  Error  Probability  (CEP)  applied  to  each  SAR  image. 
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This  simulated  image  is  data  collected  over  a  dune  region. 
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This  simulated  image  is  several  successive  data  collections  merged  together  for  display  purposes.  The 
dark  feature  that  forks  is  a  river  bed.  The  hypsographic  overlay  displays  the  ground  tmth  for  aU  the 
offset  example  cultural  features  present  image.  Grey  lines  follow  the  roadwajre.  CEP  is  evident  in  the 
registration  of  the  last  image  with  the  previous  one. 
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This  image  is  an  example  of  background  terrain  with  a  road  running  SW  to  NE.  The  granularity  and 
variation  of  the  background  are  due  to  the  low  grazing  angle  that  die  sensor  operates  at.  At  these 
angles,  the  smallest  changes  in  the  earth’s  surface  produce  high  contrast  variation  in  the  image. 
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This  image  contains  a  river  bed,  concrete  levy,  bridge,  buildings,  and  a  road.  The  large  building  viewed 
above  the  river  is  a  representation  created  from  DFAD  data  that  is  not  accurate  enough  to  adequately 
describe  the  structure.  Many  DFAD  buildings  are  described  as  omnidirectional  and  extremely  large. 
They  are,  in  actuality,  a  complex  of  many  buildings  aU  having  various  heights  and  orientations.  The 
government  will  be  “fixing’  DFAD  to  better  describe  these  type  of  structures.  ARIES  relies  on  the 
database  to  be  correct  for  accurate  representation. 


E-23 


This  image  represents  a  salt  flat  feature.  The  courseness  of  the  surrounding  terrain  next  to  the  salt  flat  is 
evident  by  the  hi^  contrast  variation  viewed  in  the  image.  The  smoother,  finer  areas  represent  the 
actual  salt  flat.  The  flats  themselves  are  geometric  in  shape  and  were  probably  man-made  along  the 
edges.  A  road  is  evident  running  through  the  center  of  the  image,  as  is  a  building  that  appears  as  a  bright 
specular  response  in  the  center. 


5.  Factory  Acceptance  Testing 

A  test  suite  of  images  has  been  established  as  the  baseline  regression  and  factory  acceptance  test  for  the 
ARIES  product.  Each  ARIES  requirement  is  mapped  to  at  least  one  test  image  which  demonstrates 
ARIES  ability  to  support  that  requirement.  Additional  test  cases  are  provided  to  validate  system 
performance  and  accuracy. 

5.1  Requirements  versus  Test  Cases 

Table  5.1-1  defines  all  ARIES  requirements  and  maps  each  to  a  test  case.  The  test  cases  are  described 
in  the  table  that  follows.  All  test  cases  have  been  run  and  the  images,  FID  (Feature  Identification)  maps, 
shadow  maps,  gain  maps  (based  on  geometry  and  reflectivity  of  the  surface)  and  other  ouQJut 
information  examined  to  verily  accuracy. 

Table  5.1-1  ARIES  Requirements 


Req  # 

Test# 

Requirements 

100 

1 

ARIES  will  simulate  a  JSTARS  SAR  image  in  real-time  on  a  DEC  Alpha 
600/533  workstation  as  specified  in  the  Classified  Appendix 

110 

2 

ARIES  shall  implement  an  earth  curvature  corrected  coordinate  system. 

120 

3 

ARIES  shall  simulate  a  fixed  image  size  with  dimensions  of  2  km  x  4  km. 

130 

3 

ARIES  shall  simulate  an  image  with  constant  resolution  in  range  and  azimuth. 

140 

4 

ARIES  shall  simulate  images  in  the  slant  plane. 

150 

4 

ARIES  shall  generate  a  magnitude  simulated  image. 

160 

4 

ARIES  shall  simulate  leading  edge  effects. 

170 

ARIES  shall  simulate  the  effects  of  range  layover. 

190 

2 

ARIES  shall  simulate  the  effects  of  obscuration  along  the  sensor  line-of-sight 

200 

4 

ARIES  shall  simulate  a  single  look  c^abiUty. 

210 

4 

ARIES  shall  simulate  a  focused  Spot  SAR. 

220 

4 

ARIES  shall  simulate  depression  angles  up  to  12  degrees  relative  to  horizon. 

230 

4 

ARIES  shall  simulate  a  maximum  squint  angle  of  +/-  60  degrees  off  broadside. 

240 

ARIES  shall  simulate  summer  seasonal  conditions. 

250 

ARES  shall  simulate  clear  atmospheric  conditions. 

260 

6 

ARES  shall  simulate  calm  wind  conditions. 

270 

4 

ARES  shall  simulate  SAR  imagery  in  accordance  with  JSTARS  sensor 
performance  parameters. 

280 

4 

ARES  shall  simulate  X-band. 

290 

4 

ARES  shall  simulate  HH  polarization. 
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300 

3 

ARIES  shall  simulate  a  single  resolution  in  range  and  azimuth  as  specified  in 
the  classified  appendix. 

320 

2 

ARIES  shall  use  an  elevation  database  for  simulating  topographical  effects 
within  a  simulated  image. 

325 

8 

ARIES  shall  support  an  elevation  database  which  encompasses  an  area  up  to 
512  kmx  512  km. 

330 

4 

ARIES  shall  use  a  feature  database  to  locate  natural  and  cultural  features 
within  a  simulated  image. 

340 

2 

ARIES  shall  accept  earth  curvature  corrected  elevation  data  from  the  GEE 
database. 

350 

2 

ARIES  shall  accept  earth  curvature  corrected  feature  data  from  the  GEE 
database. 

360 

4 

ARIES  shall  accept  point  feature  data. 

370 

4 

ARIES  shall  accept  linear  feature  data. 

380 

26 

ARIES  shall  accept  areal  feature  data. 

390 

n/a 

ARIES  shall  incorporate  effects  of  features  and  topography  which  lie  outside 
of  Area  of  Interest  (AOI)  that  influence  obscuration  within  the  AOI. 

420 

8 

Rocky  flats  (maximum  boulder  size  of  1  foot) 

430 

9 

Packed  sand  and  gravel 

440 

4 

Loose  sand 

450 

10 

Windblown  dunes 

460 

11 

Dry  depressions  with  sandy  bottoms 

470 

12 

Wadis 

480 

13 

Escarpments 

490 

14 

Salt  marshes 

500 

15 

Salt  flats 

510 

16 

Elood  Plains 

520 

4 

Date  palm  orchards 

530 

17 

Irrigated  fields 

540 

4 

Buildings 

550 

4 

Cylindrical  storage  tanks 

560 

4 

OH  wells 

570 

2 

Above  ground  pipelines 

580 

18 

Soil/sand/dirt  berms  referred  to  as  revetments 

590 

19  ^ 

Below  ground  sand/dirt  trenches 

600 

4 

Above  ground  concrete  and  dirt  bunkers 

610 

19 

Sand/dirt  ditches 

620 

4 

Paved  roads 

630 

20 

Unpaved  roads 

640 

21 

Loose  dirt  trails  (less  than  1  road  width) 

650 

2 

Railroad  tracks 
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660 

4 

Airfields  -  composed  of  buildings  and  runways 

670 

4 

Transmission  towers  -  4  sided  pyramidal 

680 

4 

Electric  power  lines 

690 

22 

Dirt  and  concrete  dikes  and  levees 

700 

23 

Dirt  and  concrete  walls  and  berms 

710 

19 

Anti-tank  ditches 

720 

2 

Pipelines  within  trenches 

730 

24 

Quarries 

740 

2 

Chain  link  fences 

750 

2 

Concertina  fences 

760 

2 

Barbed  wire  fences 

770 

2 

Bridges 

800 

4 

ARIES  shall  simulate  moving  targets. 

810 

4 

ARIES  shall  simulate  stationary  targets. 

830 

4 

Tanks,  ie.  T-72,  T-72  w/plow,  T-72  w/mine  roller,  T-54/55 

840 

4 

Air  Defense  Systems,  ie.  Long  Track  Radar,  MTLB,  ZSU-23-4 

850 

4 

Armored  Personal  Carrier,  ie.  BMP-1,  BMP-2,  MTLB 

860 

4 

Artillery,  i.e.  2S1, 2S3 

870 

4 

Armored  Cars,  ie.  BRDM  w/machine  guns,  BRDM  w/AT-5s,  BTR-60,  BTR 
w/120mm  mortars. 

880 

4 

Artillery,  i.e.  BM-21,  BM-22,  D-30,  T-12 

890 

4 

Support  Trucks,  i.e.  UAZ-469, 5-Ton  CAC,  5-ton  fuel,  2  'A-ton  cargo 

900 

4 

MI-24 

910 

4 

MI-8  Hip 

920 

4 

HAVOC 

930 

4 

ARIES  shall  support  TEL  targets. 

940 

b2.1 

ARIES  shall  simulate  SAR  imagery  in  accordance  with  data  provided  through 
an  interface  with  Northrop  Grumman's  RPSI  as  specified  in  the  ARIES-RPSI 
Interface  Control  Document. 

950 

b2.1 

All  coordinates  passed  to  ARIES  through  the  RPSI  shall  be  relative  to  a 
topocentric  coordinate. 

960 

b2.1 

Area  of  Interest  Centeroid  (x,y,z)  (m) 

970 

b2.1 

Resolution  (m) 

980 

b2.1 

Wavelength  (m) 

990 

b2.1 

Dwell  Time  (s) 

1000 

b2.1 

Azimuth  extent  (radians) 

1010 

b2.1 

Range  extent  (m) 

1020 

b2.1 

Sensor  position  (x,y,z)  (m) 

1030 

b2.1 

Sensor  velocity  vector  (m/s) 

1040 

b2.1 

Antenna  orientation  vector 

1050 

b2.1 

Number  of  targets  within  image 

1060 

b2.1 

For  each  target  in  the  image  area.  Target  category,  ie.  tank,  tmck,  launcher 
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1070  b2.1 

1080  b2.1 

1090  b2.1 

1100  b2.1 

1110  b2.1 

1120 

1170  b2.1 

1180  b2.1 

1190  b2.1 


1200  1 
1210  b2.1 

1220 

1230  b2.1 

1260  b2.1 


1300  b2.1 


1310  b2.1 


For  each  target  in  the  image  area.  Target  subcategory,  ie.  M-1,  M-60 

For  each  target  in  the  image  area,  Target  specifics 

For  each  target  in  the  image  area.  Target  position  centroid  (x,y,z)  (m) 

For  each  target  in  the  image  area.  Target  velocity  vector  (m) 

For  each  target  in  the  image  area.  Target  orientation  vector 

For  each  target  in  the  image  area,  target  appearance 

ARIES  software  shall  execute  on  the  Alpha  600  5/333  workstation. 

LM  shaft  have  1GB  of  RAM  on  the  Alpha  600  5/333  dedicated  to  ARIES 
during  simulation  activity. 

ARIES  executable  software  and  resident  operating  system  shaft  have  access 
to  100%  of  the  processing  resource  CPU  time  on  the  Alpha  600  5/333 
during  simulation  activity. 

ARIES  software  shaft  execute  under  OpenVMS,  version  6.2  or  later. 

ARIES  software  shaft  be  compatible  with  the  RPSI  environment. 

ARIES  software  shaft  return  a  pass  status  upon  successful  completion  of 
image  generation. 

ARIES  software  shaft  return  a  fail  status  upon  unsucessfiji  completion  of  image 
generation. 

ARIES  shaft  pass  image  data  to  the  RPSI  with  2000/R  pixels  in  cross-range 
by  4000/R  pixels  in  range  where  R  is  the  resolution  parameters  in  meters 
passed  by  the  RPSI. 

ARIES  software  shaft  accept  a  Ground  Reference  Coverage  Area  (GRCA)  as 
input  from  the  RPSI  as  specified  in  the  ARIES  -  RPSI  Interface  Control 
Document. 

ARIES  shall  simulate  an  image  which  is  completely  encompassed  by  the 
GRCA  boimdaries. 


5.2  Test  Cases  Defined 

Tables  5.2-1  defines  the  test  cases  and  describes  what  each  test  case  involves. 

Table  5.2-1  Test  Care  Description 

Test  #  Tide  Description 

1  Alpha  Execution  Run  alpha  test  program  on  both  the  SUN  and  the  alpha  with 

default  values  to  generate  an  image  ouQ)ut  file.  Verify  the 
image  from  the  alpha  matches  the  same  image  generated  on 
the  SUN.  This  image  is  generated  using  the  small  library, 
small  DFAD  and  small  GRCA. 
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2 


Terrain  /  Shadow  /  Output  is  the  shadow  map  from  8  different  angles  of  the  same 
Feature  Verfication  terrain.  Print  and  align  the  maps  to  verify  terrain  matches  in 
all.  AOI  is  at  0, 0.  Final  image  contains  artificial  features  used 
for  quality  verification.  These  image  contains  a  feature  of 
known  height  in  known  terrain  at  known  depression  angles. 
Verify  shadow  length. 

3  Resolution  Distortion  Compare  with  test  #2  for  different  resolution  in  X  and  Y. 

4  General  Image  Generate  airport  scene  and  verify  image  quality  of  contained 

Quality  features.  Print  out  feature  maps  and  align  to  verify  constant 

location  of  features.  Image  contains  all  target  types  and 
moving  targets. 

5  Terrain  /  Feature  Print  the  gain  and  the  feature  maps  and  overlay  to  verify  match 

Matching  between  the  two. 

6  Windy  Run  only  the  first  few  images  and  compare  the  windy  palm 

trees  with  the  calm  palm  trees  in  test  4. 

7  GRCA  Test  Different  sizes  and  shapes  of  GRCA's  in  different  ARIES  of 

the  database.  Verify  features  and  terrain. 

8  Coarse  +  Smooth  Image  shows  the  coarse  texture  contained  within  the  smooth 
Textures  +  Stream  +  texture  background. 

Mnt. 

9  Fine  +  Smooth  Image  shows  the  fine  texture  contained  within  the  smooth 

Textures  texture  background. 

10  Dunes  +  Smooth  Image  shows  an  area  of  sand  dunes  within  flie  smooth  texture 

background. 

1 1  Dry  Depression  Sample  image  of  feature  and  other  missing  items 

12  Wadi  See  test  11 

13  Escarpments  Sample  image  of  feature 

14  Salt  Marshes  Sample  image  of  feature 

1 5  Salt  flats  +  Pipeline  Sample  image  of  feature 

1 6  Flood  Plains  Sample  image  of  feature 

1 7  Irrigated  fields  See  test  1 1 

18  Soil/sand/dirt  berms  See  test  1 1 
referred  to  as 
revetments 

19  Below  ground  See  test  1 1 

sand/dirt  trenches 

20  Unpaved  roads  +  Sample  image  of  feature 
Ocean 

21  Loose  dirt  trails  (less  Sample  image  of  feature 
than  1  road  width)  + 

Dry  Lake 

22  Dirt  and  concrete  Also  includes  orchards,  power  plants,  telephone  poles  and 
dikes  and  levees  wires  and  a  real  bridge! 
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23 

Dirt  and  concrete 
walls  and  berms 

!  Sample  image  of  feature 

24 

Quarries 

Sample  image  of  feature 

25 

Divided  Hiway 

Sample  image  of  feature 

26 

Area  Features 

This  is  a  set  of  artificial  area  features  designed  to  challenge  the 
area  feature  routines.  Print  the  FID  maps  and  verify 
alignment. 

27 

Timing 

Run  a  set  of  images  on  sarsim  using  a  complete  but  reduced 
Ubraiy  to  assess  actual  timing. 

28 

Odd  angles 

General  test  at  odd  angles,  compare  FID  maps  with  those 
from  test  4. 

29 

Linear 

Test  pattern  of  linear  objects. 

30 

Runways 

Dual  runways 

31 

Orchards 

Orchard  areas. 

5.3 

Real  Time  Processing  Predictions 

Table  5.3-1  illustrates  the  allocated  and  projected  image  processing  times.  The  projected  execution  at 
NG  was  32.7  seconds.  The  actual  execution  time  for  the  same  image  was  24  seconds.  Execution  time 
will  vary  depending  on  image  contents.  During  build  3  delivery  at  NG  reliable  execution  times  as  high  as 
30  seconds  were  noted.  This  is  aU  still  below  the  projected  time. 

Table  5.3-1  Allocated  and  Projected  Image  Processing  Times 


Allocated 

Timing  Predictions 

Actual  Times 

CSC 

% 

Target  Sun  Ultra  1 

Host  Times  Timing 
Required  Allocation 

based  on 
Build  2 

benchmark 

Actual  Predicted  vs  Predicted 
Timings  Actual  Host 

on  Sun  Timing  Execution 

Ultra  1  Differences  Times  based 
on  Sun  Ultra  on  Build  2 
1  benchmark 

% 

20.00 

22.14 

48.70 

90% 

44.00 

Process  RPSI  Data 

0.00 

0.00 

0.00 

0.00% 

External  Obscuration 

1.00 

1.11 

1.11 

0.00 

0.00% 

Transform  AOI 

1.00 

1.11 

1.11 

0.00 

0.00% 

Generate  Point  Map 

5.00 

5.53 

koo ' 

-2.47 

7.23 

22.11% 

3D  to  2D  Projection 

3.00 

3.32 

2.00 

1.32 

1.81 

5.53% 

Chip  &  Texture 

3.00 

3.32 

7.00 

-3.68 

6.32 

19.34% 

Final  Image  Proc. 

7.00 

7.75 

15.47 

-7.72 

13.98 

42.75% 

Image  Output 

0.00 

0.00 

3.72 

;-3.72 

3.36 

10.28% 

Totals 

100.00% 

20.00 

22.14 

36.19 

-14.05 

32.70 

100.00 

% 
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Initializatioii 


271.05 


Table  5.3-2  uses  the  measured  execution  times  from  the  SUN  scaled  to  the  original  image  size  of  1024 
X  512  pixels.  The  projected  execution  time  here  is  well  within  the  time  allotment  when  processing  this 
size  of  image. 
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Table  5.3-2  Measured  Execution  Time  frSAR 


Allocated 

Timing  Predictions 

Actual  Times 

CSC 

% 

Target 

Sun  Ultra  1 

Actual 

Predicted  vs  Predicted 

% 

Host  Times  Timing 

Timings 

Actual 

Host 

Required 

Allocation 

on  Sun  Timing 

Execution 

based  on 

Ultra  1 

Differences 

Times  based 

Build  2 

on  Sun  Ultra  on  Build  2 

benchmark 

1 

benchmark 

20.00 

22.14 

48.70 

90% 

44.00 

Process  RPSI  Data 

0.00% 

0.00 

0.00 

0.00 

0.00 

External  Obscuration 

5.00% 

1.00 

1.11 

1.11 

0.00 

Transform  AOI 

5.00% 

1.00 

1.11 

1.11 

0.00 

Generate  Point  Map 

25.00% 

5.00 

5.53 

2.'48  , 

3.05 

2.24 

24.10% 

3D  to  2D  Projection 

15.00% 

3.00 

3.32 

P-62 

2.70 

0.56 

6.02% 

Chip  &  Texture 

15.00% 

3.00 

3.32 

ii7  ^ 

1.15 

1.96 

21.09% 

Final  Image  Proc. 

35.00% 

7.00 

7.75 

3.87  V 

i3.88 

3.49 

37.58% 

Image  Output 

0.00% 

0.00 

0.00 

1.15 

-1.15 

1.04 

11.21% 

Totals 

100.00% 

20.00 

22.14 

10.29 

11.85 

9.30 

100.00 

% 

Initialization 

Ipioo""', 

271.05 

6.  Final  Build  Summary 

ARIES  final  build  was  a  great  success.  The  customer  indicated  overwhelming  satisfaction  with  the 
product  and  with  the  Lockheed  Martin  TDS-Arizona  ARIES  team  members.  The  following  paragraphs 
discuss  the  outcome  of  the  software  integration. 

A  software  delivery  was  made  to  Northrop  Grumman  (NG)  in  June  97.  This  had  constituted  the  “fixes” 
of  Build  2.  NG  was  given  10  days  to  integrate  the  software  and  inform  LMTDS  of  a  successful 
integration.  Because  no  report  was  given  on  the  status  of  the  integration,  LMTDS  assumed  aU  had  gone 
well.  It  became  evident  two  weeks  prior  to  the  last  buUd  (August  25)  that  NG  had  not  integrated  the 
Build  2  software  fixes  and  was  now  encountering  problems  associated  with  trying  to  integrate  it  late  in 
August. 

During  Build  2,  there  was  still  some  integration  issues  that  dealt  with  the  resolution  of  the  display  images 
and  how  both  LMTDS  and  NG  would  treat  those  displays.  Because  it  was  not  known  ahead  of  time 
what  the  display  size  is  in  azimuth  from  run  to  run,  it  was  agreed  that  Lockheed  Martin  would  alwa)^ 
return  the  same  size  image.  It  was  up  to  NG  to  crop  the  image  as  needed  to  match  the  display  size 
required.  NG  attempted  to  fix  the  resolution  issue  without  success.  The  images  were  appearing  skewed 
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upon  display  at  NG.  Because  this  was  not  the  case  at  LM,  clearly,  it  was  a  display  function  that  needed 
to  be  fixed  in  NG  display  routines.  LM  provided  all  the  detail  of  our  processing  via  telephone  and  e- 
maU,  and  informed  NG  exactly  what  needed  to  be  done  on  their  end  to  fix  the  problem.  Weeks  passed 
with  no  response.  To  resolve  this  issue,  LM  funded  an  unscheduled  trip  for  David  Corgan  to  go  to  NG 
and  fix  this  and  any  other  problems  (some  of  which  were  unknown)  that  occured.  LM  realized  that  the 
display  ratio  problem  was  a  matter  of  NG  passing  the  azimuth  width  in  radians  of  the  final  image  size, 
not  of  the  size  that  ARIES  passes  back  to  the  RPSI. 

While  a  number  of  items  were  identified  for  further  analysis  and  possible  future  modifications,  only  one 
item  was  identified  as  a  priority  change.  The  target  chips  appeared  too  small  to  be  visible  on  the  NG 
display.  Because  they  were  deemed  “too  large”  at  LM  the  week  prior,  this  was  a  surprising  result.  LM 
was  also  asked  to  remove  the  antenna  “rolloff’  function  that  made  the  image  appear  darker  as  a  function 
of  azimuth.  Because  the  rolloff  boosted  the  targets  to  be  more  visible,  removing  it  made  them  fade  into 
the  background.  LM  analyzed  the  images  on  our  own  system  and  remade  the  targets.  The  appearance 
of  the  targets  in  the  images  will  not  be  verified  until  a  set  of  images  is  executed  at  NG  and  send  to  LM 
for  analysis.  The  displays  are  slightly  different  and  ultimate  verification  is  made  by  viewing  on  the  NG 
system. 

NG  had  mentioned  that  the  contrast  ratio  was  not  correct  in  the  simulated  images.  NG  offered  the 
Signal-to-Noise  ratio  (SNR)  as  a  “fix”  to  determing  the  proper  contrast  ratio.  LM  does  not  see  the 
correlation  between  the  value  of  the  SNR  and  adjusting  the  contrast  ratio  based  on  this  value.  The 
contrast  ratio  between  two  areas  of  the  image  is  a  ratio  of  the  image  intensities  in  the  two  areas-not  the 
signal-to-noise  ratio.  The  contrast  ratio  of  the  simulated  images  matched  that  of  the  real  images  when 
measured  on  byte  scaled  data  between  shadow  and  flat  terrain.  The  real  images  that  were  used  as  an 
example  for  the  simulated  images  also  were  heavily  attenuated  due  to  a  loss  of  anterma  power  across 
the  image.  Therefore,  choosing  an  area  that  best  described  the  area  to  emulate  was  a  subjective  matter. 
The  contrast  ratio  of  one  area  in  the  real  data  varied  greatly  firom  another.  LM  had  requested  the  IQ 
data  for  each  of  the  images.  This  would  have  provided  the  necessary  absolute  values  of  the  clutter, 
targets,  and  noise  that  a  single  SNR  value  cannot  provide.  The  images  that  LM  were  given  were 
postprocessed  through  a  weighted  histogram  equalization  routine  that  distributed  the  byte  scale  detected 
data  in  a  way  that  was  xmknown  to  LM.  Therefore,  going  fi’om  this  format  to  determining  the  IQ  values 
would  not  be  possible.  The  images  were  also  provided  without  ground  tmth  i.e.,  it  was  not  known 
whether  some  of  the  targets  were  moving  thereby  appearing  larger  and  brighter  than  normal. 

The  following  items  were  software  fixes  that  occurred  during  integration  and  test  at  NG. 

1 .  CEP  was  divided  by  two  to  produce  less  error  and  be  more  characteristic  of  the  system. 

2.  Target  chips  were  scaled  to  be  brighter  by  a  factor  of  20  upon  initialization.  This  was  rectified  by 
increasing  tiie  size  of  the  targets. 

3 .  Antenna  attenuation  as  function  of  azimuth  was  deleted. 
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4.  New  moving  target  response.  The  LM  applied  response  did  not  visually  match  the  processing  that 
NG  does  for  the  real  data,  as  no  ground  tmth  has  been  delivered  with  the  example  images.  NG 
“fixed”  the  moving  target  response  by  applyiug  a  phase  error  in  an  omnidirectional  way  with  no 
regard  for  die  aircraft  velocity  direction  relative  to  target  motion.  This  is  not  an  acceptable  solution 
to  LM  for  integration  into  ARIES  and  will  be  revisited  at  a  later  date.  It  is  clearly  NOT  possible  for 
the  phase  error  to  be  omnidirectional.  Phase  errors  due  to  uncompensated  motion  are  visibly 
apparent  in  azimuth  only. 

5.  Targets  and  texture  chips  were  “inserted”  into  background,  not  added. 

6.  The  elevation  backgrounds  were  scaled  down  by  a  factor  of  5  for  dry  lake  beds  and  flat  ground. 

Although  the  customer  had  accepted  the  above  fixes  as  the  critical  modifications  that  needed  to  be 

done,  LM  identified  the  following  modifications  to  include  into  Build  3. 

1 .  New  Target  chips  implemented  into  library  -  remove  scaling  at  initialization 

2.  CEP  divided  by  two  is  implemented  in  hbraiy 

3 .  Fix  missing  middle  of  runways 

4.  Revisit  the  antenna  rolloff  procedure  and  address  the  image  intensity  without  this  process. 

5 .  Lower  water  level  for  more  leading  edge  on  shores 

6.  ■  Implement  smooth  soil  background  on  orchards 

7 .  Verify  possibility  of  missing  target  at  end  of  hst. 

The  following  items  were  identified  during  Build  3  dehvery  for  modification  during  the  next  ARES 

phase. 

1 .  Road  beds  for  highways 

2.  Implement  variable  quad  tree  depth 

3.  GUI 

4.  External  Obscuration 

5.  Shadow  enhancements 

6.  Terrain  elevation  grid  registered  with  GRCA 
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7.  Move  CSCI-1  tables  to  library 

8.  Enhanced  testing  display  tool 


9.  Moving  target  response 
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1.  Scope 


This  document  defines  the  contents  of  the  messages  to  and  from  the  Ground  Station  Modde  (GSM) 
over  a  T-1  LAN  interface  for  incorporation  into  the  RADAR  Processor  Simulator  and  Integrator 
(RPSI)  on  the  Joint  STARS  platform. 

1.1  Purpose 

The  purpose  of  this  document  is  to  define  the  interface  requirements  between  Northrop  Grumman  and 
Motorola  regarding  the  RPSI.  The  RPSI  is  being  developed  for  the  integration  of  Joint  STARS  into  the 
Joint  Advanced  Distributed  Simulation  (JADS)  environment. 

1.2  Application 

Interface  requirements  set  forth  in  this  document  apply  during  the  development  and  laboratory  testing  of 
the  RPSI. 

1.3  Definitions  and  Conventions 

The  following  conventions  were  used  to  describe  each  message  interface: 

•  High  Level  Message  Elements 

a.  Message  Name. 

b.  Brief  functional  description  of  the  message. 

•  Characteristics  (Intermediate  message  elements): 

a.  Source,  Destination,  Via,  Transmission  rate,  and  Size. 

b.  Word  Nirmber 

c.  Word  Signal  Name:  either  contains  the  actual  field  name  or  a  functional  name  that  best 
describes  the  fields  within  each  message. 

d.  Units:  describes  the  engineering  units  to  be  applied  against  the  word  being  described. 

e.  MIN/MAX  Range:  describes  the  valid  minimum  and  maximum  range  of  values.  If  a  single 
number  is  used,  the  min./max.  Range  is  constant.  If  a  number  is  enclosed  parenthetically,  (N), 
the  number  is  +  N.  The  minimum  and  maximum  range  are  evenly  divisible  by  the  least  significant 
bit  (LSB).  Words  that  are  encoded  wiU  have  a  min/max  supplied  as  N/A. 


F-  7 


f.  Least  Significant  Bit  (LSB):  The  LSB  is  defined  to  be  bit  00,  illustrated  as  the  rightmost  bit  of  a 
word.  The  LSB  value  is  the  weighting  (scale  factor)  of  the  LSB. 

g.  Type:  this  describes  the  FORTRAN  data  type  that  is  applied  to  the  word  being  described. 

•  Field  Descriptions: 

a.  Word  Number:  being  described. 

b.  Field  name  of  field  being  described. 

c.  Engineering  Units,  as  described  in  the  message  Characteristics  Table.  Units  can  be  described 
as  bit  encoded,  meaning  a  bit  map  is  required  to  fully  define  the  field.  Units  can  also  be 
described  value  encoded,  meaning  the  numeric  value  of  the  field  means  something  other  than  the 
numeric  itself 

d.  LSB  (when  applicable)  is  supplied  describing  the  weighting  of  the  least  significant  bit. 

e.  Min/Max  Range  (when  applicable)  is  supplied  to  describe  the  valid  minimum  and  maximum 

range  of  the  feild  being  described. 

•  Other  Nomenclature: 

a.  Spare  Fields  are  noted  in  word  pictures  as  “XX”  fields.  All  spare  fields  are  assumed  to  be 
zero. 

b.  Most  Significant  Bit  (MSB):  The  most  significant  bit  is  defined  to  be  bit  15,  shown  as  the 
leftmost  bit  of  the  word. 

c.  Hexadecimal  Representation:  numbers  represented  in  hexadecimal  will  be  noted  using  a  lower 
case  “x”.  For  example  the  hex  number  OF  will  be  shown  as  either  ‘OF’x  or  OFx. 
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2.  Referenced  Documents 


Document  Number  Title  Date 

C99ICDVA345  The  Airborne  Data  Terminal  06  January  1995 

(ADT)  Surveillance  and 
Control  Datalink  (SCDL) 

ProducibiUty  Program  Joint 
Surveillance  Target  Attack 
Radar  System  (JOINT 
STARS) 


3.  Message  Definitions 

This  section  will  identify  those  messages  which  will  be  supported  by  the  RPSI  and  the  added  header 
information  necessary  for  transmission  over  the  T-1  LAN  interface.  The  LAN  interface  will  be  a 
Standard  802.3  LAN  and  shall  use  the  UDP  protocol. 

3.1  Messages  To  ADT 

The  following  paragraphs  contain  the  messages  normally  sent  to  the  ADT  by  the  1553  bus  controller. 
These  messages  in  the  normal  system  operations  are  described  in  the  referenced  ICD. 

3.2  Control  Messages 

These  messages  are  normally  sent  to  the  ADT  by  the  E-8  1553  Bus  Host  and  in  general  control  the 
timing  and  priority  of  downlinked  messages.  The  messages  are  Control,  Adaptive  Control  A,  and 
Adaptive  Control  B  they  will  not  be  transmitted  over  the  LAN. 

3.2.1  Downlink  Data  Header 

A  downlink  message  is  data  normally  received  by  the  ADT,  via  the  1553  Bus,  to  be  transmitted  on  the 
SCDL.  The  word  formats  as  modified  for  retransmission  on  the  T-1  are  as  follows: 
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Donwlink  Data  Header 

Message  Name:  Data  Header 
Source:  RPSI 
Destination:  GSM 
Xmit  Rate:  Asynchronous 
Size:  29  Words 


Word 

Signal  Name 

Units 

Range 

Init  value 

LSB 

Type 

01 

Message  ID 

ID 

9100x 

N/A 

1 

1*2 

02 

Message  Type 

Coded 

N/A 

N/A 

N/A 

1*2 

03 

GDT  Address 

Coded 

N/A 

N/A 

N/A 

1*2 

04-29 

Data 

Coded 

N/A 

N/A 

N/A 

1*2 

Word  1 —  JADS  Message  E)  this  word  is  the  JADS  message  identification. 

Word  2  -  Bit  0-4  Message  Type 

Bit  5-11  Serial  Number.  The  value  0  is  not  a  valid  serial  number.  This  fact  is  used  by  the 
receiving  GDT  to  distinguish  a  Downlink  message  from  a  relay  message. 

Word  3  -  Bit  0  GDT  Address 

Bit  1-2  Identifies  the  packet  type  as  follows: 

00  =  Report  Packet 
01  =  Dwell  Packet 

10  =  Object  Packet 

11  =  Single  Packet 

Bit  3  is  dependent  upon  the  value  of  the  Packet  ID  it  is  normally  supplied  by  the  ADT 
software  and  is  defined  as  follows: 


When  Packet  ID  equals: 


00  =  Report  Packet 
01  =  Dwell  Packet 

10  =  Object  Packet 

11  =  Single  Packet 


Bit  3  set  indicates  an  acknowledgment  is  required. 

Bit  3  has  no  significance 

Bit  3  set  indicates  last  packet  of  message. 

Bit  3  set  indicates  an  acknowledgment  is  required. 


This  BIT  will  not  be  simulated  by  the  JADS  T-1  LAN  interface. 

Bits  4-15  Utility  Field.  User  defined  by  the  message  originator  (operator)  to  provide 
information  to  the  GSM  1553  Bus  Host  about  the  downlink  message.  The  definition  of 
the  information  contained  in  this  field  is  dependant  on  the  value  of  the  Packet  ID  and  can 
be  used  by  the  GSM  operator  to  obtain  the  following  information: 
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When  Packet  ID  equals: 


00  =  Report  Packet  Utility  Field  contains  the  total  count  of  Dwell  or  Object 
Headers  in  the  message. 

01  =  Dwell  Packet  UtiUty  Field  contains  the  serial  number  for  the  Dwell 
Packet. 

10  =  Object  Packet  Utihty  Field  contains  the  serial  number  for  the  Object 
Packet. 

11  =  Single  Packet  Utility  Field  may  contain  data. 

Word  4-29  Data 

Bit  0-15  Data. 

3.2.2  Aircraft  Location 

The  Aircraft  Lxxation  is  a  bus  message  containing  the  Latitude,  Longitude,  Altitude  of  the  aircraft,  the 
time  delay  and  the  current  attitude  of  the  aircraft  in  roll  and  pitch.  The  word  formats  as  modified  for 
retransmission  on  the  T-1  are  as  follows: 

Aircraft  Location 

Message  Name:  Aircraft  Location 
Source:  RPSI 
Destination:  GSM 
Xmit  Rate:  Asynchronous 
Size:  9  Words 


Word 

Signal  Name 

Units 

Range 

Init  value 

LSB 

Type 

01 

Message  ID 

ID 

9200X 

N/A 

1 

P2 

02 

Latitude  MSB 

DEG 

0-90 

N/A 

8.32x10-® 

1*2 

03 

Latitude  LSB 

DEG 

0-90 

N/A 

8.32x10'® 

1*2 

04 

Longitude  MSB 

DEG 

0-180 

N/A 

8.32x10-® 

1*2 

05 

Longitude  LSB 

DEG 

0-180 

N/A 

8.32x10'® 

1*2 

06 

Altitude 

Meters 

32767.5 

N/A 

.5 

1*2 

07 

Time  Delay 

msec 

2550 

N/A 

10 

1*2 

08 

Aircraft  Roll 

DEG 

255.5 

N/A 

.5 

1*2 

09 

Aircraft  Pitch 

DEG 

255.5 

N/A 

.5 

1*2 

Word  1 —  JADS  Message  ID  this  word  is  the  JADS  message  identification. 
Word  2  -  Bit  0  Sign  of  Latitude.  0  =  North,  1  =  South. 
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Bit  1  -  15,  15  Most  Significant  Bits  of  the  aircraft  latitude.  (Note:  the  ADT  truncates  the 
data,  using  only  the  6  MSBs  of  this  word  before  downlinking  to  the  GDI) 

Word  3  -  Bit  0-15  Latitude,  16  Least  Significant  Bits  of  the  aircraft  latitude. 

Word  4  -  Bit  0  Sign  of  Longitude.  0  =  East,  1  =  West. 

Bit  1  -  15,  15  Most  Significant  Bits  of  the  aircraft  longitude.  (Note:  the  ADT  truncates  the 
data,  using  only  the  6  MSBs  of  this  word  before  downlinking  to  the  GDI) 

Word  5  -  Bit  0-15  Longitude,  16  Least  Significant  Bits  of  the  aircraft  longitude 

Word  6  -  Bit  0-15  Altitude,  Aircraft  Altitude.  (Note:  The  ADT  truncates  the  data  using  only  the  12 
MSBs  of  this  word  before  downlinking  to  the  GDT). 

Word 7 -Bit  0-7  Spare 

Bit  8-15  Time  Delay,  the  delay  from  the  aircraft  position  measurement  to  its  transmittal  on 
the  1553  Bus  to  the  ADT. 

Word  8  -  Bit  0-6  Spare 

Bit  7-15  Aircraft  Roll  Angle,  absolute  value  of  roU  angle. 

Word  9  -  Bit  0-6  Spare 

Bit  7-15  Aircraft  Pitch  Angle,  absolute  value  of  pitch  angle. 

3.2.3  Polling  Control 

The  polling  control  is  sent  to  the  ADT  by  the  E-8  to  establish  the  polling  sequence  (uplink  channel 
assignment).  The  polling  control  message  will  not  be  transmitted  on  the  T-1 . 

3.3  Messages  From  The  ADT 

This  section  contains  those  messages  normally  transmitted  by  the  ADT  to  the  Bus  Host  via  the  1553 
data  bus. 

3.3.1  Transmit  Vector  Words 

A  message  responding  to  a  poU  for  uplink  and  relay  data  available  fix)m  the  ADT  since  last  poll.  This 
message  will  not  be  used  for  the  T-1  LAN  implementation. 
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3.3.2  Uplink  Data  Header 

An  Uplink  Message  is  data  normally  received  on  the  SCDL  by  the  ADT.  This  message  will  received 
from  the  GSM  via  the  T-1  LAN  interface  and  processed  by  the  RPSI.  The  format  is  9s  shown: 

Uplink  Data  Header 

Message  Name:  Uplink  Data  Header 

Source:  GSM 

Destination:  RPSI 

Xmit  Rate:  Asynchronous 

Size:  29  Words 


Word 

Signal  Name 

Units 

Range 

Init  value 

LSB 

Type 

01 

Message  ID 

ID 

9300x 

N/A 

1 

1*2 

02 

Signal  Strength 

Coded 

N/A 

N/A 

N/A 

1*2 

03 

H  Fields 

Coded 

N/A 

N/A 

N/A 

1*2 

04 

Message  Info 

Coded 

N/A 

N/A 

N/A 

1*2 

05-28 

Data 

Coded 

N/A 

N/A 

N/A 

1*2 

29 

Message  Length 

Coded 

N/A 

N/A 

N/A 

1*2 

Word  1 —  JADS  Message  ID  this  word  is  the  JADS  message  identification. 

Word  2  -  Bit  0  -7  Signal  Strength.  Not  used  in  JADS 
Bit  8  - 15  Signal  Quality.  Not  used  in  JADS 

Word  3 —  Bit  0  -  4  H  Fields,  are  set  by  the  ADT’s  receiver  hardware  to  provide 
information  on  the  uplink  message.  Not  used  in  JADS. 

Bit  5-15  Identifier,  set  to  “1”  to  indicate  an  Uplink  message. 

Word  4  -  Bit  0-3  Data,  first  four  bits  of  the  message. 

Bit  4-8  Sender  Address,  valid  addresses  are  16,26,  or  21  for  an  uplink.  If  monitor  all 
uplinks  bit  is  set  addresses  1  through  15  are  also  valid  (relay  messages). 

Bit  14-15  message  Code,  designates  the  function  of  the  message  as  follows: 

00  =  No  acknowledgment  Required. 

01  =  Acknowledgment  Required. 

10  =  Acknowledgment  to  Downlink  packet  or  Relay  message. 

11=  Uplink  acquisition  message. 

Bit  14-15  will  not  be  used  in  JADS. 

Word  5-28  -  Data. 
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Word  29  -  Long  Message 


Bit  0-2  Number  of  ACK  Tries.  Not  used  in  JADS. 

Bit  3  Data  Length,  ignored  by  the  ADT.  Not  used  in  JADS. 

Bit  4-15  Data. 

Short  Message 

Bit  0-2  Number  of  ACK  Tries.  Not  used  in  JADS. 

Bit  3  Data  Length.  Not  used  by  JADS. 

Bit  4-15  Data.  Vahd  only  for  long  messages. 

3.3.3  Deleted  Data 

A  message  in  response  to  a  command  for  the  deleted  data.  The  Deleted  Data  message  provides  the 
ADT  operator  with  message  type,  serial  number  and  deletion  code  for  each  downlink  message  that  is 
deleted  up  to  thirty-one  messages.  This  message  wiU  not  be  implemented  on  flie  T-1  interface. 

3.3.4  Status 

The  Status  message  provides  the  status  information  for  the  ADT.  This  message  will  not  be  implemented 
on  the  T-1  LAN  interface. 
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1  SCOPE 


1.1  Identification 

This  software  test  plan  (STP)  applies  to  the  computer  software  configuration  item  (CSCI)  portion  of  the 
Ground  Data  Terminal  (GDT)  1553  Bus  Interface  Unit  (1553  BIU).  The  development  of  the  GDT 
1553  BIU  is  under  the  direction  of  the  Joint  Advanced  Development  Simulation  (JADS)  Joint  Test  and 
Evaluation  (JT&E)  End-to-End  Test  (ETE)  organization  at  Kirtland  AFB  in  New  Mexico. 

1.2  System  Overview 

The  JADS  JT&E  organization  is  charged  with  developing  the  capabUily  to  test  and  evaluate  the  Joint 
STARS  system  performance  through  a  hardware-in-the-loop  simulation.  One  element  of  this  simulation 
is  the  interface  between  the  Common  Ground  Station  (CGS)  and  tiie  E-8C  aircraft.  This  interface  is 
normally  an  RF  link.  The  link  is  to  be  simulated  by  sending  link  data  over  a  dedicated  T1  line.  This 
requires  the  development  of  interface  software  at  both  ends  of  the  T1  line  to  make  the  data  look  like  it 
had  traversed  the  Surveillance  Control  Data  Link  (SCDL)  rather  than  a  WAN  based  digital  connection. 
The  specific  software  under  test  here  is  the  interface  software  for  the  CGS  end  of  the  T1  line. 

1.3  Document  Overview 

This  STP  describes  the  formal  qualification  test  plans  for  the  GDT  1553  BIU.  It  identifies  the  software 
test  environment  resources  required  for  formal  qualification  testing  (FQT)  and  provides  schedules  for 
FQT  activities.  In  addition,  it  identifies  the  individual  tests  that  shall  be  performed  during  FQT. 

1.4.  Relationship  to  Other  Plans 

There  are  no  other  plans  related  to  this  particular  activity  at  the  current  contract  level. 
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2.  Referenced  Documents 


Document  Number  Document  Title  Document  Date 


JADS-ICD-002 

Interface  Control  Document  for  the 
Ground  Station  Module  T-1  LAN 
Interface  of  the  Radar  Processor 
and  Integrator  for  Joint  STARS 

January  1997 

C99ICDVA331 

Interface  Control  Document  (ICD) 
for  Ground  Station  Module  (GSM) 
Target  Acquisition  Subsystem  to 
Ground  Data  Terminal  (GDT) 
Group  OZ-64/GRY  Containing 
LRU’s  Nonienclatured  (V)3/G 

15  April  1996 

3.  Software  Test  Environment 


3.1  Software  Items 

The  software  items  necessary  to  perform  the  FQT  activities  include: 
Sun  Solaris  operating  system, 

Sun  C-H-  compiler, 

EDT  1553  device  driver, 

GDT  1553  BIU  application  code, 

CGS  1553  test  drivers,  and 
ADT  802.3  test  drivers. 

3.2  Hardware  and  Firmware  Items 


The  computer  hardware,  interfacing  equipment,  and  firmware  items  that  will  be  used  in  the  software  test 
environment  include: 


Sun  SPARC  5  computer  (the  application  host). 
Sun  computer  (the  802.3  interface  emulator). 
Sun  computer  (the  1553  interface  emulator). 
Joint  STARS  Common  Ground  Station  (CGS), 
JADS  supplied  IDNX, 

JADS  supplied  KIV-7HS,  and 
JADS  supplied  CSU/DSU. 
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The  test  environment  for  CSCI  testing  will  be  unclassified.  The  test  environment  for  system  level  testing 
may  include  classified  information.  Whether  or  not  the  system  level  test  information  is  classified,  the 
testing  will  include  encryption  /  decryption  equipment  as  part  of  the  test  setup. 

3.3  Propritary  Nature  and  Government  Rights 

There  are  no  proprietary  rights  on  the  developed  software,  hardware,  or  firmware. 

3.4  Installation,  Testing  and  Control 

The  GDT  1553  BIU  application  code  will  be  installed  on  the  Sun  SPARC  5  computer  prior  to  test. 
The  apphcation  code  and  all  test  software  will  be  maintained  under  Configuration  Management  Version 
Control  (CMVC)  prior  to  and  during  the  tests. 

4.  Formal  Qualification  Test  Identification 

4.1  GDT  1553BIUCSCI 

4.1.1  General  Test  Requirements 

The  formal  qualification  of  the  GDT  1553  BIU  CSCI  shall  involve  the  use  of  nominal  input  values. 
Testing  with  erroneous  input  values  will  not  be  included. 

4.1.2  Test  Classes 

The  formal  qualification  testing  of  the  GDT  1553  BIU  CSCI  shall  include  functional  tests  and  timing 
tests. 

4.1.3  Test  Levels 

The  formal  qualification  testing  of  the  GDT  1553  BIU  CSCI  shall  be  performed  at  two  levels: 

a.  CSCI  level~to  evaluate  compliance  with  CSCI  requirements.  These  tests  include  test  defirtitions 
4. 1.4.1  through  4. 1.4.9. 

b.  System  level--to  validate  that  the  SCDL  interface  performs  properly  in  the  absence  of  the  real 
GDT.  These  tests  will  be  similar  in  nature  to  the  tests  performed  for  CSCI  testing,  but  they  will 
generally  be  performed  with  real  1553  and  802.3  interfaces  rather  than  the  interface  emulators  used 
in  the  CSCI  testing.  These  tests  include  test  definitions  4.1.4.10  through  4.1.4.14 
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4.1.4  Test  Deflnitions 


4. 1. 4. 1  GD  T  Initial  Status 

a.  Test  objective:  Verify  that  the  initial  GDT  status  reports  indicate  that  the  uplink  and  downlink  are 
not  enabled  and  that  the  other  status  report  elements  are  correct  for  this  condition. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  not  send  a  control  message  that 
enables  the  uplink  or  downlink. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class;  Functional, 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  GDT  Status  Reports. 

g.  Assumptions  and  constraints:  None. 

4.1.4.2  GDT  Initial  Status  Message  Blocking 

a.  Test  objective:  Verify  that  uplink  and  downlink  traffic  are  not  passed  through  the  GDT  1553 
BIU. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  not  send  a  control  message  that 
enables  the  uplink  or  downlink. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  Presence  or  absence  of  uplink  messages  at  the  802.3  interface  or 
downlink  messages  at  the  1553  interface. 

g.  Assumptions  and  constraints:  The  1553  interface  emulator  is  sending  uplink  messages  and  the 

802.3  emulator  is  sending  downlink  messages. 

4.1.4.3  GDT  Initial  Status  Transition 

a.  Test  objective:  Verify  that  the  GDT  status  reports  indicate  that  the  uplink  and  downlink  are 
enabled  after  receipt  of  the  uplink  and  downlink  enabling  control  messages  from  file  1553  emulator. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  first  enable  the  downlink  and  then 
enable  the  upUnk. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Fimctional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  GDT  Status  Reports. 

g.  Assumptions  and  constraints:  The  GDT  1553  BIU  must  start  this  test  in  the  Initial  Status  Mode 
of  paragraph  4. 1 .4. 1 . 
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4.1.4.4  GDT  Uplink  Messages 


a.  Test  objective:  Verify  that  uplink  traffic  is  correctly  passed  through  the  GDT  1553  BIU. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  have  already  enabled  the  uplink  and 
downlink. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  Uplink  messages  at  the  802.3  interface. 

g.  Assumptions  and  constraints:  The  1553  emulator  is  providing  periodic  uplink  messages. 

4.1.4.5  GDT  Uplink  Message  Latency 

a.  Test  objective:  Verify  that  upUnk  traffic  is  correctly  passed  through  the  GDT  1553  BIU  with  a 
latency  of  less  than  100  milliseconds. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  have  already  enabled  the  uplink  and 
downlink. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Timing. 

e.  Qualification  method:  Demonstration. 

f  Type  of  data  to  be  recorded:  Time  of  Uplink  message  appearance  at  the  1553  and  802.3 
interfaces. 

g.  Assumptions  and  constraints:  The  1553  emulator  is  providing  periodic  uplink  messages. 

4.1.4.6  GDT  Downlink  Messages 

a.  Test  objective:  Verify  that  downlink  traffic  is  correctly  passed  through  the  GDT  1553  BIU. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  have  already  enabled  the  uplink  and 
downlink. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f  Type  of  data  to  be  recorded:  Downlink  messages  at  the  1553  interface. 

g.  Assumptions  and  constraints:  The  802.3  emulator  is  providing  periodic  downlink  messages. 

4.1.4. 7  GDT  Downlink  Message  Latency 

a.  Test  objective:  Verify  that  downlink  traffic  is  correctly  passed  through  the  GDT  1553  BIU  widi 
a  latency  of  less  than  100  milliseconds. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  have  already  enabled  the  uplink  and 
downlink. 

c.  Test  level:  CSCI. 
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d.  Test  type  or  class:  Timing. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  Downlink  messages  at  the  1553  interface. 

g.  Assumptions  and  constraints:  The  802.3  emulator  is  providing  periodic  downlink  messages. 

4.1.4.8  GDI  Aircraft  Location  Messages 

a.  Test  objective:  Verify  that  the  Aircraft  Location  Message  is  correctly  converted  and  passed 
through  the  GDT  1553  BIU  in  the  GDT  Status  Report. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  have  already  enabled  the  uplink  and 
downlink. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  GDT  Status  Reports  at  the  1553  interface. 

g.  Assumptions  and  constraints:  The  802.3  emulator  is  providing  periodic  aircraft  location 
messages. 

4. 1.4.9  GDT  Traffic  Capacity 

a.  Test  objective:  Verify  that  GDT  1553  BIU  traffic  capacity  is  sufficient  to  pass  28  DoAvnlink 
messages  and  one  Uplink  message,  to  process  one  Aircraft  Location  message,  to  provide  one  GDT 
Status  message  and  two  Transmit  Vector  Words  messages  during  a  100  millisecond  time  interval. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  have  already  enabled  the  uplink  and 
downlink. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Timing. 

e.  Qualification  method:  Demonstration. 

f  Type  of  data  to  be  recorded:  Time  of  Uplink  message  appearance  at  the  1553  and  802.3 
interfaces;  time  of  Downlink  message  appearance  at  the  802.3  and  1553  interfaces;  time  of  Aircraft 
Location  messages  appearance  at  the  802.3  interface;  and  time  of  GDT  Status  and  TVW  messages 
appearance  at  the  1553  interfaces. 

g.  Assumptions  and  constraints:  All  required  messages  are  provided  to  the  GDT  1553  BIU  CSCI 
at  the  proper  rates. 

4.1.4.10  GDT  Initial  Status 

a.  Test  objective:  Verify  that  the  initial  GDT  status  reports  indicate  that  flie  uplink  and  downlink  are 
not  enabled  and  that  the  other  status  report  elements  are  correct  for  this  condition. 

b.  Special  requirements:  For  this  test,  the  CGS  must  not  send  a  control  message  that  enables  the 
uplink  or  downlink. 

c.  Test  level:  System. 

d.  Test  type  or  class:  Functional. 
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e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  GDT  Status  Reports. 

g.  Assumptions  and  constraints:  None. 

4.1.4.11  GDT  Initial  Status  Transition 

a.  Test  objective:  Verify  that  the  GDT  status  reports  indicate  that  the  uplink  and  downlink  are 
enabled  after  receipt  of  the  uplink  and  downlink  enabling  control  messages  from  the  1553  emulator. 

b.  Special  requirements:  For  this  test,  the  CGS  must  first  enable  the  downlink  and  then  enable  the 
uplink. 

c.  Test  level:  System. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

£  Type  of  data  to  be  recorded:  GDT  Status  Reports. 

g.  Assumptions  and  constraints;  The  GDT  1553  BIU  must  start  this  test  in  the  Initial  Status  Mode 
of  paragraph  4. 1 .4.7. 

4. 1.4.12  GD  T  Uplink  Messages 

a.  Test  objective:  Verify  that  uplink  traffic  is  correctly  passed  through  the  GDT  1553  BIU. 

b.  Special  requirements:  For  this  test,  the  CGS  must  have  already  enabled  the  uplink  and 
downlink. 

c.  Test  level:  System. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method;  Demonstration. 

f.  Type  of  data  to  be  recorded;  Uplink  messages  at  the  E-8C  interface  at  Northrop  /  Grumman. 

g.  Assumptions  and  constraints:  The  CGS  is  providing  periodic  uplink  messages. 

4.1.4.13  GDT  Downlink  Messages 

a.  Test  objective:  Verify  that  downlink  traffic  is  correctly  passed  through  the  GDT  1553  BIU. 

b.  Special  requirements:  For  this  test,  the  CGS  must  have  already  enabled  the  uplink  and 
downUnL 

c.  Test  level;  System. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  Downlink  messages  at  the  CGS. 

g.  Assumptions  and  constraints;  The  E-8C  is  providing  periodic  downlink  messages. 
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4. 1.4.14  GD  T  Aircraft  Location  Messages 


a.  Test  objective:  Verify  that  the  Aircraft  Location  Message  is  correctly  converted  and  passed 
through  the  GDT  1553  BIU  in  the  GDT  Status  Report. 

b.  Special  requirements:  For  this  test,  the  CGS  must  have  already  enabled  the  uplink  and 
downlink. 

c.  Test  level:  System. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  GDT  Status  Reports. 

g.  Assumptions  and  constraints:  The  E-8C  is  providing  periodic  aircraft  location  messages. 

4.1.5  Test  schedule 

The  testing  of  the  GDT  1553  BIU  CSCI  shall  be  accomphshed  as  soon  as  practical  after  this  STP 
receives  JADS  ETE  approval  and  dry-run  testing  verifies  that  the  software  passes  the  tests  in 
paragraphs  4. 1.4.1  through  4. 1.4.9  of  this  STP.  The  system  level  testing  of  tiie  GDT  1553  BIU  CSCI 
shall  be  accomphshed  as  soon  as  practical  after  completion  of  the  CSCI  level  testing.  The  system  level 
tests  are  defined  in  paragraphs  4.1.4.10  through  4.1.4.14. 

5.  Data  Recording,  Reduction,  and  Analysis 

The  data  reduction  and  analysis  required  during  and  following  the  tests  identified  in  this  STP  will  be 
comparison  of  GDT  Status  Reports,  Uplink  Messages,  and  Downlink  Messages  with  their  respective 
expected  values  and  evaluation  of  appropriate  timing  entries  for  message  transmit  and  receipt.  No  data 
retention  will  be  required  other  than  logbook  entries  and  printouts  generated  during  the  tests. 

6.  NOTES 

None. 
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JADS  BIU  Qualification  Test  Procedure 


Three  test  configurations  are  identified  herein  to  support  the  test  levels  and  definitions  described  by  the 
previously  submitted  Software  Test  Plan.  This  procedure  describes  each  test  configuration,  tests 
conducted  for  that  configuration,  and  a  brief  procedure  for  each  test.  All  test  definitions  fi'om  the 
Software  Test  Plan  are  included  within  this  procedure;  however  ,  they  will  be  executed  in  accordance 
with  the  test  configuration  order  presented  below. 

Test  Configuration  I 

Software  Emulation  of  CGS  running  on  JADS  BIU  workstation 

JADS  BIU  Software  running  on  JADS  BIU  workstation 

Software  emulation  of  T1  Link  running  on  “Kong”  workstation 

Triax  termination  on  Primary  1553  connector  which  links  the  CGS  emulation  software  to  the  JADS  BIU 
software  via  1553  bus. 

Ethernet  Link  between  JADS  BIU  and  “Kong”  network 

When  each  of  the  three  software  components  have  been  initiated,  the  CGS  Emulator  will  send  control 
messages  and  uplink  messages  (  rate  =  0.1  Hz)  to  the  BIU  over  the  1553  bus,  automatically  triggering 
the  GDT  status  transitions.  The  T1  link  emulator  software,  upon  receiving  the  first  uplink  message  firom 
the  BIU  over  the  Ethernet  link,  will  respond  by  sending  downlink  messages  (  rate  =  80  Hz)  and  aircraft 
location  messages  (  rate  =  1  Hz).  When  the  JADS  BIU  software  transitions  to  the  downlink  enabled 
mode,  it  will  pass  the  messages  through  the  1553  bus  where  they  wiU  be  detected  by  the  CGS  Emulator 
software.  Results  of  the  tests  will  be  verified  by  examination  of  log  files  generated  as  the  above  scenario 
is  executed. 

Test  Configuration  I  Coverage 

a)  GDT  Initial  Status  (STP  Paragraph  4. 1.4.1) 

Verify  Control  Word  portion  of  initial  GDT  Status  Report  from  CGS  Emulator  Log  File 

b)  GDT  Initial  Status  Message  Blocking  (STP  Paragraph  4. 1.4.2) 

Examine  JADS  BIU  Log  File  to  verify  that  Uplink  messages  are  counted  only  when  Uplink  is  enabled, 
and  that  Downlink  messages  are  counted  only  when  downlink  is  enabled. 

c)  GDT  Initial  Status  Transition  (STP  Paragraph  4. 1.4.3) 
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Examine  JADS  BIU  Log  File  to  verify  that  Uplink  Enabled  and  Downlink  enabled  mode  transitions  take 
place. 

d)  GDT  Uplink  Messages  (STP  Paragraph  4. 1.4.4) 

Examine  T1  Emulator  Log  File  to  verify  tire  indication  of  test  uplink  messages  passed  through  the  JADS 
BIU  and  transmitted  via  Ethernet  to  the  “Kong”  workstation. 

e)  GDT  Uplink  Message  Latency  (STP  Paragraph  4. 1.4.5) 

Examine  JADS  BIU  Log  File  to  record  maximum  and  average  Uplink  latency  values  in  milliseconds. 

f)  GDT  Downlink  Messages  (STP  Paragraph  4. 1.4.6) 

Examine  JADS  BIU  Log  File  to  record  maximum  and  average  Uplink  latency  values  in  miUiseconds. 

g)  GDT  Aircraft  Location  Messages  (STP  Paragraph  4. 1.4.7) 

Examine  CGS  Emulator  Log  Files  to  verify  the  indication  of  Aircraft  Location  data  updating  the 
appropriate  fields  of  the  GDT  Status  message. 

Test  Configuration  II 

CGS  Server  1553  connection  to  provide  downlink  data  request 

JADS  BIU  Software  running  on  JADS  BIU  workstation 

Software  emulation  of  T1  Link  running  on  “Kong”  workstation 

Cable  connection  between  Primary  1553  connector  which  links  the  CGS  server  to  the  JADS  BIU 
software  via  1553  bus. 

Ethernet  Link  between  JADS  BIU  and  “Kong”  network 

Requests  for  downlink  data  are  generated  periodically  (20  Hz)  by  the  CGS  Server.  The  T1  link 
software  emulation  generates  aircraft  location  &  downlink  messages  at  a  rate  which  is  comparable  to 
that  supported  by  the  actual  T1  hnk  maximum.  Uplink  messages  will  be  generated  from  the  CGS 
workstation  console,  and  when  the  first  message  is  passed  through  the  JADS  BIU  to  the  T1  emulation 
software,  downlink  and  aircraft  location  message  transmission  will  begin.  Results  of  the  tests  will  be 
verified  by  log  files  generated  on  the  JADS  BIU  workstation. 

Test  Configuration  II  Coverage 
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a)  GDT  Downlink  Latency  (STP  Paragraph  4. 1.4.7) 

Examine  JADS  BIU  Log  FUe  to  record  maximum  and  average  Downlink  latency  values  in  milliseconds. 

b)  GDT  Traffic  Capacity  (STP  Paragraph  4. 1.4.9) 

Examine  JADS  BIU  Log  File  to  record  maximiun  throughput  rate  in  messages  per  second. 

Test  Configuration  III 

CGS  Server  1553  connection  to  JADS  BIU  workstation 

E8  Aircraft  Simulator  Connection  to  JADS  BIU  workstation  ( Tl/  IDNX  ) 

The  workstation  will  require  re-configuration  and  re-boot  to  incorporate  new  IP  address  and  port  data , 
which  are  necessary  to  support  its  operational  configuration. 

Test  Configuration  III  Coverage 

a)  GDT  Initial  Status  (STP  Paragraph  4. 1. 4. 10) 

Capture  GDT  Status  report  at  CGS  Console  using  Bus  Monitor  Log  facility. 

b)  GDT  Initial  Status  Transition  (STP  Paragraph  4. 1.4.1 1) 

Use  CGS  Manage  Links  controls  and  periodic  status  displays  on  JADS  BIU  console  to  verify  the  status 
transitions. 

c)  GDT  Aircraft  Location  Messages  (STP  Paragraph  4.1.4.14) 

Use  CGS  Workstation  hnageiy  window  to  display  the  simulated  E  -  8C  flight  path. 

d)  GDT  Uplink  Messages  (STP  Paragraph  4.1.4.12) 

Generate  RSR  &  Freetext  messages  using  CGS  Workstation  and  confirm  receipt  at  Grumman  facility. 

e)  GDT  Downlink  Messages  (STP  Paragraph  4.1.4.12) 

Use  CGS  Message  Alert  facihty  to  display  Freetext  message  originated  from  the  simulated  E  -  8C  ;  use 
imagery  window  to  display  MTI  &  SAR  imagery  patterns. 
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APPENDIX  H 


Memorandum  for  Record 
Characterization  Reports 


From 

JADS  JTF/ETE  (N&E) 


H-  1 


H-  2 


MEMORANDUM  FOR  RECORD 


16  Dec  97 


FROM:  JADS JTF/ETE(N&E) 

SUBJECT:  Characterization  Report 

1.  Event  Name:  TCAC-Grumman  T-1  Characterization. 

2.  Date/Time:  1  Dec  97;  1100  -  1500. 

3.  Site(s):  Grumman  -  Melbourne,  FL;  JADS  TCAC  -  Albuquerque,  NM. 

4.  Description:  The  characterization  involved  base-lining  the  performance  of  the  T-1  link  between 
Grumman  and  the  TCAC.  A  variety  of  Networking  and  Engineering  tests  were  used  to  calculate  the 
round  trip  latencies  and  determine  the  maximum  rate  at  which  DIS  PDUs  could  be  transmitted  before 
drop-outs  occurred.  The  tests  used  to  gather  this  data  included  the  No  Load  Latency  Test,  the  Loaded 
Latency  Test,  PDU  Verification  Test  and  the  Stress  Test.  Additionally,  Spectrum  recorded  the 
bandwidth  utilized  across  the  T-1  link. 

5.  Objective:  Assess  (characterize)  the  TCAC-Grumman  T-1  Link  with  and  without  network  analysis 
tools  operating. 

5.1  Determine  the  “no  load”  latency  using  pings. 

5.2  Determine  the  loaded  latency  using  pings  at  varying  rates. 

5.3  Successful  transmission  ofDIS  PDUs  across  the  link. 

5.4  Determine  the  packet  rate  (packets  per  second)  in  which  DIS  PDUs  are  lost. 

5.5  Determine  the  impact  of  Spectrum  on  latencies  and  data  rates. 

6.  Results: 

6. 1 .  Data  Recorded  (with  Spectrum  operational) 

6.1.1  No  Load  Latency  Test:  The  first  test  conducted  was  the  no  load  latency  test  using 
pings.  This  test  involved  using  32  pings  for  measuring  the  baseline  round  trip  latency  from  the  TCAC  to 
Grumman.  The  minimum  load  for  these  pings  were  64  bytes.  This  test  yielded  the  following  results: 


Table  6.1.1.  Latency  Test  -  No  Load 


Date 

Source 

Destination 

No.  Pkts 

Round-trip  Time  ( 

^ms) 

Mininium 

Maximum 

Average 

1  Dec  97 

TCAC_Indy 

32 

57 

71 

57 
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6. 1 .2.  Loaded  Latency  Test:  The  second  test  consisted  of  transmitting  loaded  pings,  144 
bytes,  at  several  different  rates  and  packet  sizes  to  determine  the  round  trip  latencies-  see  table  6.1.2. 


Table  6.1.2.  Latency  Test  -  Loaded 


Date 

Source 

Destination 

Pkt 

Rate(sec) 

Pkts 

Sent/Rec 

Rounc 

l-trip  Time  (ms)  | 

Min 

Max 

Ave 

1  Dec  97 

TCAC_Indy 

Grumman_Indy 

.01 

320/320 

58 

163 

60 

.005 

640/639 

58 

61 

58 

.0025 

1280/1279 

58 

58 

.00125 

2560/2559 

58 

58 

6.1.3.  PDU  Verification  Test:  The  next  test  used  PDUs  generated  at  100  packets  per  second 
from  JANUS  and  recorded  by  the  JADS  logger.  The  PDUs  were  replayed  from  the  TCAC  and 
logged  at  Grumman  -  see  table  6.1.3. 


Table  6.1.3.  PDU  Verification  Test 


Date 

Location 

No.  of  PDUs 
Received 

No.  of  PDUs 
Transmitted 

No.  of  PDUs 
Out-of-order 

No.  of  PDUs 
>  1  sec. 

5  Nov  97 

Grumman 

11859 

11859 

0 

0 

6.1.4.  Stress  Test:  This  test  involved  replaying  the  ESPDU  file  at  its  recorded  excepted  data 
rate  (EDR),  then  increasing  the  EDR  by  100  packets  per  second  incrementally  to  five  times  the  EDR. 
During  the  actual  playback  of  the  PDU  log  file,  pings  were  transmitted  and  latency  statistics  recorded. 
Spectrum  also  recorded  the  bandwidth  utilized. 


Table  6.1.4.  Stress  Test 


Rate 

(PDU/sec) 

Ping  Time  (ms) 
Min/Max/Ave 

Number  PDUs 
Received 

Bandwidth 

Util.  (%) 

1  X  E.R. 

60/120/61 

11859 

10 

59/90/68 

11858 

21 

3XE.R. 

59/90/64 

11853 

28 

4  X  E.R. 

57/210/79 

11847 

5XE.R. 

500 

57/840/256 

10492 

45  1 

6.2.  Data  Recorded  (without  Spectrum  operational) 
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6.2. 1  No  Load  Latency  Test:  The  first  test  conducted  was  the  no  load  latency  test  using 
pings.  This  test  involved  using  32  pings  for  measuring  the  baseline  round  trip  latency  from  the  TCAC  to 
Grumman.  The  minimum  load  for  these  pings  were  64  bytes.  This  test  yielded  the  following  results: 


Table  6.2.1.  Latency  Test  -  No  Load 


Date 

Source 

Destination 

No.  Pkts 

Round-trip  Time  (ms) 

Minimurn 

Maximum 

Average 

1  Dec  97 

TCAC_Indy 

Grumman_Indy 

32 

57 

76 

57 

6.2.2.  Loaded  Latency  Test:  The  second  test  consisted  of  transmitting  loaded  pings,  144 
bytes,  at  several  different  rates  and  packet  sizes  to  determine  the  round  trip  latencies-  see  table  6.2.2. 


Table  6.2.2.  Latency  Test  -  ] 

Loaded 

Date 

Source 

Destination 

Pkt 

Rate(sec) 

Rounc 

-trip  Time  (ms) 

Max 

Ave 

TCAC_Indy 

Grumman_Indy 

.01 

320/320 

58 

■■ 

■■nnn 

.005 

640/639 

58 

64 

58  1 

.0025 

1280/1279 

58 

58 

58 

6.2.3.  PDU  Verification  Test:  The  next  test  used  PDUs  generated  at  100  packets  per  second 
from  JANUS  and  recorded  by  the  JADS  logger.  The  PDUs  were  replayed  from  the  TCAC  and 
logged  at  Grumman  -  see  table  6.2.3. 


Table  6.2.3.  PDU  Verification  Test 


Date 

Location 

No.  of  PDUs 
Received 

No.  of  PDUs 
Transmitted 

No.  of  PDUs 
Out-of-order 

No.  of  PDUs 
>  1  sec. 

5  Nov  97 

Grumman 

11859 

11859 

0 

0 

6.2.4.  Stress  Test:  The  last  test  conducted  was  the  Stress  Test.  The  test  involved  replaying 
the  ESPDU  file  at  its  recorded  EDR,  then  increasing  the  EDR  by  100  packets  per  second  incrementally 
to  five  times  the  EDR.  During  the  actual  playback  of  the  PDU  log  pings  were  transmitted  and 
latency  statistics  recorded;  however,  bandwidth  data  was  not  collected. 
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Table  6.2.4.  Stress  Test 


Rate 

(PDU/sec) 

Ping  Time  (ms) 
Min/Max/Ave 

Number  PDUs 
Received 

Bandwidth 

Util.  (%) 

1XE.R. 

100 

60/70/60 

11859 

2XE.R. 

200 

58/92/62 

11858 

3XE.R. 

300 

59/89/63 

11853 

4XE.R. 

400 

57/120/71 

11848 

5XE.R. 

500 

57/600/216 

6.3.  Problems: 

6.3.1.  The  characterization  process  was  delayed  for  a  couple  of  hours  due  to  the  monthly 
crypto  reloading. 

6.3.2.  During  the  PDU  Verification  test  additional  DIS  PDUs  were  being  logged  at  the 
Grumman_Indy  computer.  The  DIS  PDUs  logged  at  Grumman  exceeded  the  number  contained  in  the 
replayed  log  file  sent  fi-om  the  TCAC.  The  Grumman_Indy  computer  can  receive  data  fi-om  both 
Grumman  and  the  TCAC.  The  test  coordinator  contacted  Grumman  and  inquired  as  to  whether  they 
had  a  system  broadcasting  to  the  Grumman_Indy  computer  on  port  3000.  Grumman’s  initial  response 
to  our  question  was  no.  Upon  our  investigation,  which  consisted  of  viewing  traffic  along  port  3000,  we 
observed  the  Grumman_Indy  computer  receiving  data  long  after  we  had  stopped  broadcasting. 
Apparentiy,  Grumman  had  concluded  a  test  last  week,  but  their  Alpha  computer  was  still  sending  data 
to  port  3000.  Finally,  Grumman  disconnected  their  Alpha  computer  and  we  resumed  testing  with  no 
further  problems  or  delays. 

6.3.3.  The  IDNX  router  card  throughput  is  presently  less  than  the  vendor’s  specification  and 
the  allocated  capacity  of  the  T-1  link.  The  performance  can  be  improved  if  we  used  bridging  as 
opposed  to  Internet  Protocol  (IP)  routing  of  DIS  PDUs.  This  procedure  was  assessed  using  the  JADS 
testbed.  The  effect  of  bridging  doubled  the  reliable  transmitted  data  rate  to  800  packets  per  second. 
However,  this  configuration  does  not  support  the  current  network  design  of  the  ETE  test.  The  vendor 
was  contacted  about  the  shortcoming,  and  they  are  pursuing  every  avenue  to  determine  if  the 
performance  problem  is  their  software,  Cisco's  software,  or  hardware  related. 

6.3.4  Although  the  utilized  bandwidth  was  accurately  recorded  using  Spectrum  for  one,  two, 
and  three  times  the  EDR,  the  values  for  four  and  five  times  seemed  lower  than  expected.  The 
percentages  were  20  and  19,  respectively.  The  data  collection  sampling  interval  was  initial  set  for  every 
30  seconds.  Consequently,  the  DIS  PDUs  were  not  replayed  within  the  time  window  and  the  results 
were  not  representative  of  the  EDR.  The  settings  were  reduced  to  10  second  intervals  and  Spectrum’s 
packet  rate  data  was  monitored  to  ensure  the  values  reflected  the  EDR. 
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6.3.5.  The  maximum  value  recorded  for  each  set  of  pings  represented  an  outlier  of  the  data 
set.  This  maximum  value  far  exceeded  the  values  recorded  and  consistently  appeared  at  the  beginning 
of  the  recorded  data  set.  Since  this  anomaly  happened  infrequently  during  a  ping  data  set,  the  results 
were  not  statistically  significant.  N&E  will  continue  to  investigate  this  issue. 

6.4.  Summary:  At  lOOOhrs  the  characterization  team  began  the  preliminary  checks  of  the  network. 
About  one  hour  later,  the  characterization  began  and  each  one  of  the  tests  was  executed  in  sequence. 
The  test  results  were  stable  and  fairly  predicable.  During  the  Stress  Test  several  DIS  PDUs  were  lost  at 
three  and  four  times  the  EDR  but  did  not  achieve  a  notable  percentage.  However,  at  five  times  the 
EDR  several  hundred  DIS  PDUs  were  dropped— approximately  nine  percent.  Currently,  the  highest 
EDR  transmissions  across  this  link  should  not  exceed  400  packets  per  second;  therefore,  the  link  can 
successfully  handle  the  expected  traffic.  The  characterization  test  also  involved  capturing  the  impact  of 
the  network  analysis  tool.  The  results  indicated  that  Spectrum  minimally  increased  the  amount  of 
network  traffic  and  added  an  insignificant  amount  of  latency. 


GREGORY  P.  DEWIT 
CPT(P),  FA 
Test  Analyst 
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MEMORANDUM  FOR  RECORD 


26  Feb  98 


FROM:  JADS JTF/ETE/N&E 
SUBJECT:  EXE  Characterization  Report 

1.  Event  Name:  White  Sands  Missile  Range  (WSMR)/TCAC-A  Annex  T-1  Characterization. 

2.  Date/Time:  3  Feb  98;  1100  -  1500. 

3.  Sites:  WSMR,  NM;  JADS  TCAC  -  Albuquerque,  NM. 

4.  Description:  The  characterization  involved  base-Uning  the  performance  of  the  T-1  link  between 
WSMR  and  the  TCAC-A.  A  variety  of  Networking  and  Engineering  tests  were  used  to  calculate  the 
round  trip  latencies  and  determine  the  maximum  rate  at  which  DIS  PDUs  could  be  transmitted  before 
drop-outs  occurred.  The  tests  used  to  gather  this  data  included  the  No  Load  Latency  Test,  the  Loaded 
Latency  Test,  PDU  Verification  Test,  and  the  Stress  Test. 

5.  Objective:  Assess  (characterize)  the  WSMR/TCAC-A  T-1  link. 

5.1  Determine  the  “no  load”  latency  using  pings. 

5.2  Determine  the  loaded  latency  using  pings  at  varying  rates. 

5.3  Successful  transmission  of  DIS  PDUs  across  the  link. 

5.4  Determine  the  packet  rate  (packets  per  second)  in  which  DIS  PDUs  are  lost. 

6.  Results: 

6.1.  Data  Recorded. 

6.1.1  No  Load  Latency  Test:  The  first  test  conducted  was  the  no  load  latency  test  using 
pings.  This  test  involved  using  32  pings  for  measuring  the  baseline  round  trip  latency  from  the  TCAC  to 
WSMR.  The  minimum  load  for  these  pings  were  64  bytes.  This  test  yielded  the  following  results: 


Table  6.1.1.  Latency  Test  -  No  Load 


Date 

Source 

Destination 

No.  Pkts 

Round-trip  Time  ( 

:ms) 

Minimum 

Maximum 

Average 

1  Dec  97 

TCACJndy 

WSMR  Indy 

32 

41 

44 

41 

6.1.2.  Loaded  Latency  Test:  The  second  test  consisted  of  transmitting  loaded  pings,  144 
bytes,  at  different  rates  and  packet  sizes  to  determine  round  trip  latencies-  see  table  6.1.2. 
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Table  6.1.2.  Latency  Test  -  Loaded 


Date 

Source 

Destination 

Pkt 

Rate(sec) 

Pkts 

Sent/Rec 

Rounc 

[-trip  Time  (ms)  | 

Min 

Max 

Ave 

1  Dec  97 

TCAC_Indy 

WSMR  Indy 

.01 

320/320 

42 

45 

42 

.005 

640/639 

42 

85 

■9 

.0025 

960/960 

42 

51 

6.1.3.  PDU  Verification  Test:  The  next  test  used  PDUs  generated  at  100  packets  per  second 
from  JANUS  and  recorded  by  the  JADS  logger.  The  PDUs  were  replayed  from  the  TCAC  and 
logged  at  WSMR  -  see  table  6.1.3. 


Table  6.1.3.  PDL 

Verification  Test 

Date 

Location 

No.  of  PDUs 
Received 

No.  of  PDUs 
Transmitted 

No.  of  PDUs 
Out-of-order 

No.  of  PDUs 
>  1  sec. 

5  Nov  97 

WSMR 

11859 

11859 

0 

0 

6. 1 .4.  Stress  Test:  This  test  involved  replaying  the  ESPDU  file  at  its  recorded  excepted  data 
rate  (EDR),  then  increasing  the  EDR  by  100  packets  per  second  incrementally  to  five  times  the  EDR. 
During  the  actual  playback  of  the  PDU  log  pings  were  transmitted  and  latency  statistics  recorded. 

Spectrum  also  recorded  the  bandwidth  utilized. 


Table  6.1.4.  Stress  Test 


Rate  (PDU/sec) 

Ping  Time  (ms) 
Min/Max/Ave 

Number  PDUs 
Received 

1XE.R. 

59/61/59 

11859 

2  X  E.R. 

41/61/59 

11858 

3XE.R. 

41/60/45 

11853 

4  X  E.R. 

400 

41/61/58 

5XE.R. 

500 

41/70/56 

11849 

6.2.  Problems:  PDUs  were  lost  during  the  execution  of  the  Stress  Test.  N&E  continues  to 
investigate  packet  drop-outs. 

6.3.  Summary:  During  the  execution  of  the  characterization,  latencies  and  PDU  drop-outs  were 
less  than  anticipated.  Unlike  several  other  T-1  links  characterized  wtule  using  a  routed  network 
configuration,  WSMR  used  bridging.  This  technique  provided  a  much  more  stable  environment  thus 
allowing  for  lower  transmission  latencies  and  fewer  PDU  losses.  Each  characterization  test  was 
conducted  and  the  results  aimotated  in  the  previous  tables.  The  WSMR/TCAC-A  link  can  support  the 
maximum  expected  data  rate  of 400  PDUs  per  second. 
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GREGORY  P.  DEWIT 
CPT(P),  FA 
Test  Analyst 


MEMORANDUM  FOR  RECORD 


26  Feb  98 


FROM :  JADS  JTF/ETE/N&E 
SUBJECT:  Characterization  Report 

1.  Event  Name:  Fort  Hood/TCAC-A  Annex  T-1  Characterization. 

2.  Date/Time;  2  Feb  98;  0900  -  1 100. 

3.  Sites:  Fort  Hood,  TX;  JADS  TCAC  -  Albuquerque,  NM. 

4.  Description:  The  characterization  involved  base-lining  the  performance  of  the  T-1  hnk  between  Fort 
Hood  and  the  TCAC- A.  A  variety  of  Networking  and  Engineering  tests  were  used  to  calculate  the 
round  trip  latencies  and  determine  the  maximum  rate  at  which  DIS  PDUs  could  be  transmitted  before 
drop-outs  occurred.  The  tests  used  to  gather  this  data  included  the  No  Load  Latency  Test,  the  Loaded 
Latency  Test,  PDU  Verification  Test,  and  the  Stress  Test. 

5.  Objective:  Assess  (characterize)  the  Fort  Hood/TCAC-A  T-1  link. 

5.1  Determine  the  “no  load”  latency  using  pings. 

5.2  Determine  the  loaded  latency  using  pings  at  varying  rates. 

5.3  Successful  transmission  of  DIS  PDUs  across  the  link. 

5.4  Determine  the  packet  rate  (packets  per  second)  in  which  DIS  PDUs  are  lost. 

6.  Results: 

6.1.  Data  Recorded. 

6.1.1  No  Load  Latency  Test:  The  first  test  conducted  was  the  no  load  latency  test  using 
pings.  This  test  involved  using  32  pings  for  measuring  the  baseline  round  trip  latency  from  the  TCAC  to 
Fort  Hood.  The  minimum  load  for  these  pings  were  64  bytes.  This  test  yielded  the  following  results: 


Table  6.1.1.  Latency  Test  -  No  Load 


Date 

Source 

Destination 

No.  Pkts 

Round-trip  Time  ( 

:ms) 

Minimum 

Maximum 

Average 

1  Dec  97 

TCAC_Indy 

Fort  Hood  Indy 

32 

37 

77 

38 

6.1.2.  Loaded  Latency  Test:  The  second  test  consisted  of  transmitting  loaded  pings,  144  bytes, 
at  several  different  rates  and  packet  sizes  to  determine  the  round  trip  latencies-  see  table  6.1.2. 
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Table  6.1.2.  Latency  Test  -  Loaded 


Date 

Source 

Destination 

Pkt 

Rate(sec) 

Pkts 

Sent/Rec 

Rounc 

!-trip  Time  (ms)  | 

Min 

Max 

Ave 

1  Dec  97 

TCAC_Indy 

Fort  Hood  Indy 

.01 

320/320 

39 

38 

.005 

640/639 

39 

55 

39 

.0025 

960/960 

76 

39 

6.1.3.  PDU  Verification  Test:  The  next  test  used  PDUs  generated  at  100  packets  per  second 
from  JANUS  and  recorded  by  the  JADS  logger.  The  PDUs  were  replayed  fijom  the  TCAC  and 
logged  at  Fort  Hood  -  see  table  6.1.3. 


Table  6.1.3.  PDU  Verification  Test 


Date 

Location 

No.  of  PDUs 
Received 

No.  of  PDUs 
Transmitted 

No.  of  PDUs 
Out-of-order 

No.  of  PDUs 
>  1  sec. 

5  Nov  97 

Fort  Hood 

11859 

11859 

0 

0 

6.1.4.  Stress  Test:  This  test  involved  replaying  the  ESPDU  file  at  its  recorded  excepted  data 
rate  (EDR),  then  increasing  the  EDR  by  100  packets  per  second  incrementally  to  five  times  the  EDR. 
During  the  actual  playback  of  the  PDU  log  pings  were  transmitted  and  latency  statistics  recorded. 
Spectrum  also  recorded  the  bandwidth  utilized. 


Table  6.1.4.  Stress  Test 


Rate  (PDU/sec) 

Ping  Time  (ms) 
Min/Max/Ave 

Number  PDUs 
Received 

1XE.R. 

100 

40/69/59 

11859 

2XE.R. 

200 

37/60/42 

11858 

3XE.R. 

300 

50/60/59 

11853 

4  X  E.R. 

38/61/58 

11859 

5XE.R. 

37/61/54 

11859 

6.2.  Problems:  PDU  drop-out  is  a  reoccurring  problem  during  the  Stress  Test.  N&E  is  still 
investigating. 

6.3.  Summary:  The  Fort  Hood/TCAC-A  bridged  link  was  characterized  in  less  than  four  hours. 
The  appropriate  data  was  gathered  and  appears  in  the  tables  mentioned  earlier.  There  latencies  were 
stable  throughout  the  execution  of  each  test.  The  link  can  support  more  than  the  maximum  expected 
data  rate  with  only  a  couple  of  PDUs  dropped.  A  bridged  network  seems  to  offer  faster  transmission 
rates  and  fewer  PDU  drop-outs. 
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GREGORY  P.  DEWIT 
CPT(P),  FA 
Test  Analyst 
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MEMORANDUM  FOR  RECORD 


26  Feb  98 


FROM:  JADS JTF/ETE/N&E 
SUBJECT:  Characterization  Report 

1.  Event  Name:  Fort  Sill/TCAC-A  Annex  T-1  Characterization. 

2.  Date/Time:  2  Feb  98;  1300  -  1600. 

3.  Sites:  Fort  Sill,  OK;  JADS  TCAC  -  Albuquerque,  NM. 

4.  Description:  The  characterization  involved  base-lining  tire  performance  of  the  T-1  link  between  Fort 
Sill  and  the  TCAC-A.  A  variety  of  Networking  and  Engineering  tests  were  used  to  calculate  the  round 
trip  latencies  and  determine  the  maximum  rate  at  which  DIS  PDUs  could  be  transmitted  before  drop¬ 
outs  occurred.  The  tests  used  to  gather  this  data  included  the  No  Load  Latency  Test,  the  Loaded 
Latency  Test,  PDU  Verification  Test,  and  the  Stress  Test. 

5.  Objective:  Assess  (characterize)  the  Fort  Sill/TCAC-A  T-1  link. 

5.1  Determine  the  “no  load”  latency  using  pings. 

5.2  Determine  the  loaded  latency  using  pings  at  varying  rates. 

5.3  Successful  transmission  of  DIS  PDUs  across  the  link. 

5.4  Determine  the  packet  rate  (packets  per  second)  in  which  DIS  PDUs  are  lost. 

6.  Results: 

6.1.  Data  Recorded. 

6.1.1  No  Load  Latency  Test:  The  first  test  conducted  was  the  no  load  latency  test  using 
pings.  This  test  involved  using  32  pings  for  measuring  the  baseline  round  trip  latency  from  the  TCAC  to 
Fort  SiU.  The  minimum  load  for  these  pings  were  64  bytes.  This  test  yielded  the  following  results: 


Table  6.1.1.  Latency  Test  -  No  Load 


Date 

Source 

Destination 

No.  Pkts 

Round-trip  Time  ( 

"ms) 

Minimum 

Maximum 

Average 

1  Dec  97 

TCAC_Indy 

Indy 

32 

30 

40 

30 

6.1.2.  Loaded  Latency  Test:  The  second  test  consisted  of  transmitting  loaded  pings,  144 
bytes,  at  several  different  rates  and  packet  sizes  to  determine  the  round  trip  latencies-  see  table  6.1.2. 
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Table  6.1.2.  Latency  Test  -  Loaded 


Date 

Source 

Destination 

Pkt 

Rate(sec) 

Pkts 

Sent/Rec 

Rounc 

-trip  Time  (ms) 

Min 

Max 

Ave 

1  Dec  97 

TCACJndy 

Indy 

.01 

320/320 

31 

33 

31 

.005 

640/639 

31 

33 

31 

.0025 

960/960 

31 

33 

31 

6.1.3.  PDU  Verification  Test:  The  next  test  used  PDUs  generated  at  100  packets  per  second 
from  JANUS  and  recorded  by  the  JADS  logger.  The  PDUs  were  replayed  from  the  TCAC  and 
logged  at  Fort  Sill  -  see  table  6.1.3. 


Table  6.1.3.  PDU  Verification  Test 


Date 

Location 

No.  of  PDUs 
Received 

No.  of  PDUs 
Transmitted 

No.  of  PDUs 
Out-of-order 

No.  of  PDUs 
>  1  sec. 

5  Nov  97 

FortSiU 

11859 

11859 

0 

0 

6. 1 .4.  Stress  Test:  This  test  involved  replaying  the  ESPDU  file  at  its  recorded  excepted  data 
rate  (EDR),  then  increasing  the  EDR  by  100  packets  per  second  incrementally  to  five  times  the  EDR. 
During  the  actual  playback  of  the  PDU  log  pings  were  transmitted  and  latency  statistics  recorded. 
Spectrum  also  recorded  the  bandwidth  utilized. 


Table  6.1.4.  Stress  Test 


Rate  (PDU/sec) 

Ping  Time  (ms) 
Mm/Max/Ave 

Number  PDUs 
Received 

1XE.R. 

100 

30/61/58 

11859 

2XE.R. 

30/60/52 

11857 

30/61/43 

11853 

4XE.R. 

30/60/36 

11859 

5XE.R. 

30/84/300 

10656 

6.2.  Problems:  PDUs  were  lost  during  the  execution  of  the  Stress  Test.  N&E  will  continue  to 
investigate  packet  drop-outs. 

6.3.  Summary:  The  Fort  Sill/TCAC-A  link  involved  using  a  router  to  transmit  PDU  packets.  The 
latencies  were  reasonably  close  to  the  values  during  the  Grumman  Characterization  given  the  shorter 
distance  between  Albuquerque  and  Fort  Sill.  There  were  a  couple  of  packets  lost  while  incrementing 
up  to  four  times  the  EDR.  The  number  of  lost  PDUs  uicreased  to  about  10  percent  of  the  packets 
transmitted  at  five  times  the  EDR  (500  packets  per  second). 


H-16 


GREGORY  P.  DEWIT 
CPT(P),  FA 
Test  Analyst 


H-17 


APPENDIX  I 


Joint  Advanced  Distributed  Simulation 
Joint  Test  Force  (JADS  JTF) 

LWX  and  Cisco  Router  Performance  Test  Report 


1-2 


Joint  Advanced  Distributed  Simulation  Joint  Test  Force 
(JADS  JTF) 

LWX  and  Cisco  Router  Performance  Test  Report 

SUBJECT:  Integrated  Digital  Network  Exchange 

(IDNX)  LANAVAN  Exchange  (LWX)  and 
Cisco  Router  Performance  Measurement  in 
the  Broadcasting/Forwarding  of 

User  Datagram  Protocol  Environment 

AUTHOR:  MSgt  Charles  P.  Ashton,  WAN  Systems 

Engineer,  Joint  Advanced  Distributed 
Simulation  (JADS)  Joint  Test  Force  (JTF) 

Mason  S.  Ferratt,  Systems  Engineer 
Network  Equipment  Technologies  (NET) 

DATE:  December  18, 1997 


SUMMARY:  This  is  a  report  of  the  performance,  validation,  and  verification 

testing  conducted  on  the  LWX  and  external  Cisco  router  platforms  at  the  JADS-JTF  facility, 
Albuquerque,  NM.  This  document  covers  the  steps  taken  during  testing,  the  test  results,  conclusions 
drawn,  and  a  discussion  of  the  alternative  solutions  for  the  broadcasting  of  User  Datagram  Protocol 
(UDP)  traffic  through  the  JADS  JTF  End-to-End  (ETE)  network. 
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1.  Background 


The  Joint  Advanced  Distributed  Simulation  Joint  Test  Force  (JADS  JTF)  has  built  a  network  of  seven 
nodes  to  support  an  environment  linking  multiple  simulation  sites  whose  primary  apphcation  is  the 
broadcasting  of  User  Datagram  Protocol  packets  from  multiple  sites  to  multiple  sites.  The  network 
supports  the  evaluation  of  Advanced  Distributed  Simulation  (ADS)  for  the  Department  of  Defense 
(DOD)  Test  and  Evaluation  (T&E)  Community.  The  system  is  called  the  End-to-End  Test  Network 
and  the  system  under  test  is  the  Joint  Surveillance  and  Targeting  Attack  Radar  System  (JSTARS)  and 
its  associated  command  and  control  functions.  The  services  carried  by  this  network  include  the  router 
traffic  and  voice  traffic. 

The  goal  of  the  testing  conducted  December  15-16,  1997  was  to  provide  answers  to  whether  the  PX 
platforms  (PX-3,  PX-2,  and  APX)  provided  by  NET  could  support  the  demands  of  the  UDP  traffic 
load  through  the  JADS  network. 

2.  Scope  of  Testing 

1 .  Verification/vahdation  of  the  problems  witnessed  by  TSGT  Ashton 

2.  Comparison  of  the  performance  gains/losses  of  external  router  configurations 

3.  Effects  of  altering  internal  software  configuration  (buffers,  hold  queues,  etc.) 

4.  Effects  of  using  a  hybrid  routed/bridged  network 

5 .  Effects  of  a  completely  bridged  network 

3.  Description  of  PX-3  and  LWXRel.  3.01 

The  LANAVAN  Exchange  (LWX)  Release  3.01  is  a  general  purpose  router/bridge  integrated  into  the 
Integrated  Digital  Network  Exchange  (IDNX)  platform.  It  provides  internetwork  connectivity  between 
Local  Area  Networks  (LANs)  over  Wide  Area  Networks  (WANs)  through  IDNX/  90,  /70,  /20,  and 
/Micro  20  IDNX  nodes.  The  LWX  3.01,  consists  of  a  PX3  front  card  (revision  B  or  later)  and  an 
Ethernet  or  Token  Ring  interface  rear  card,  and  provides: 

—  concurrent  multi-protocol  routing  and  fallback  Media  Access  Control  (MAC)  layer  bridging 

—  up  to  8  logical  serial  connections  to  other  LWXs  or  external  routers 

—  an  Ethernet  interface  rear  card 

The  first  phase  of  LWX  3.01  only  supports  four  and  eight  port  PX3  cards.  EarUer  LWX  versions 
consisted  of  a  PX-  2,  PX-  Plus,  or  Access  PX  fix)nt  card  and  an  Ethernet  or  Token  Ring  interface  rear 
card,  and  provide  only  eight  logical  serial  connections  to  other  LWXs  or  external  routers.  LWX  Release 
3.01  supports  only  Ethernet  and  Token  Ring  (available  in  a  later  release)  interface  cards.  LWX  Release 
3.01  must  use  a  revision  B  (or  later)  PX3  card. 
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The  JADS  network  uses  four  port  PX3,  eight  port  PX-2,  and  four  port  APX  cards.  The  PX-3s  run 
LWX  Release  3.01  and  the  PX-2s  and  APXs  run  LWX  Release  2.02.06.  The  LWX  Release  3.01  is 
equivalent  to  Cisco’s  lOS  Release  11.0(9).  The  LWX  Release  2.02.06  is  equivalent  to  Cisco’s  lOS 
Release  9.1(9). 

4.  Test  Configurations 


Classified  Unclassified 


Figure  4-1  above  illustrates  a  general  configuration  of  the  JADS  ETE  network.  The  connectivity 
between  the  nodes  remained  consistent  throughout  the  testing.  However,  card  and  port  configurations 
were  varied  for  the  different  tests. 
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4.1  Point  to  Point  PX-3 


IDNX-20  IDNX-20 

w/PX-3  w/PX-3 


Figure  4.1-1  -  PX-3  to  PX-3  Configuration 

Figure  4.1-1  above  illiistrates  the  setup  used  for  the  verification/vahdation  using  two  PX-3s  point-to- 
point. 

42  Point  to  Point  PX-3s  to  APX 


IDNX-20  IDNX-20 

w/PX-3  w/APX 


Figure  4.2-1  -  PX-3  to  APX  Configuration 

Figure  4.2-1  above  illustrates  the  setup  used  for  the  verification/validation  using  one  PX-3  and  one  APX 
point-to-point. 

4.3  Cisco  4000  to  PX-3 


IDNX-20  IDNX-20 

w/HSD-2  w/PX-3 


Figure  4.3-1  -  Cisco  4000  to  PX-3  Configuration 

Figure  4.3-1  above  illustrates  the  setup  used  for  the  verification/validation  using  an  externally  connected 
Cisco  4000  running  Cisco  lOS  Release  9.1  to  a  PX-3  point-to-point.  The  Cisco  4000  was  serially 
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connected  through  an  HSD-2  port  on  the  E)NX.  The  HSD-2  port  was  mapped  to  the  distant  end  PX- 
3. 

4.4  Cisco  7000  to  PX-3 


Figure  4.4-1  -  Cisco  7000  to  PX-3  Configuration 

Figure  4.4-1  above  illustrates  the  setup  used  for  the  verification/validation  using  an  externally  connected 
Cisco  7000  running  Cisco  lOS  Release  11.x  to  a  PX-3  point-to-point.  The  Cisco  7000  was  serially 
connected  through  an  HSD-2  port  on  the  IDNX.  The  HSD-2  port  was  mapped  to  the  distant  end  PX- 
3. 


4.5  Cisco  7000  to  4000 

Cisco  7000 


Broadcaster 


IDNX-20 
w/ HSD-2 


[11 

'III  If 

ifiL 

r  ii 

li.ii 

Cisco  4000 


Logger 


Figure  4.5-1  -  Cisco  7000  to  Cisco  4000  Configuration 

Figure  4.5-1  above  illustrates  the  setup  used  for  the  verification/validation  using  an  externally  connected 
Cisco  7000  running  Cisco  lOS  Release  11.x  to  another  externally  connected  Cisco  4000  point-to- 
point.  Both  Cisco  routers  were  serially  connected  through  HSD-2  ports  on  the  IDNX.  The  HSD-2 
ports  were  mapped  end  to  end. 

4.6  Multipoint  UDP  Forwarding  &  Hybrid  Bridge/Router 

IDNX-20 
w/  PX-3 


I-IO 


Broadcaster 


Broadcaster 


|g?Sl 

IDNX-20 
w/  PX-3 

Figure  4.6-1  -  Multipoint  UDP  Forwarding  &  Hybrid  Bridge/Router  Configuration 


Figure  4.6-1  above  illustrates  the  setup  used  for  the  verification/validation  using  multiple  sources  to 
broadcast  DIS  Entity  State  PDUs  to  a  central  logger.  This  configuration  represents  a  portion  of  the 
unclassified  side  of  the  JADS  EXE  network. 
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5.  Test  Expectations 


Throughout  all  the  tests  the  Broadcaster,  an  SGI  Indy  workstation,  used  a  file  that  consisted  of  1 1,859 
Distributed  Interactive  Simulation  (DIS)  Entity  State  protocol  data  units  (PDUs).  The  SGI  workstation 
broadcasted  the  PDUs  on  its  local  area  network  (LAN)  as  User  Datagram  Protocol  (UDP)  packets. 
The  LWXs  were  configured  to  forward  these  broadcasts  through  the  network.  Each  Entity  State  PDU 
was  144  bytes  in  length.  The  Internet  Protocol  (IP)  datagram  produced  was  152  bytes  in  length.  All 
this  was  verified  using  a  Network  General  Sniffer  Protocol  Analyzer  on  the  Broadcaster  subnetwork. 

At  the  distant  end,  the  Logger,  also  an  SGI  Indy  workstation,  listened  for  UDP  broadcasts  and  counted 
the  number  received.  The  difference  is  the  number  of  packets  dropped  within  the  network. 

We  expected  to  see  a  threshold  that  each  platform  would  reach  in  terms  of  performance.  We  knew 
that  the  unreliable  nature  of  the  traffic  (UDP  broadcasts)  would  force  the  routers  to  inspect  each  packet 
since  it  was  a  broadcast,  and  forward  it  onto  each  interface.  This  activity  is  known  as  process 
switching.  The  fact  that  every  packet  sent  is  process  switched,  we  knew  there  had  to  be  a  limit  to  the 
number  of  packets  successfully  received  when  a  workstation  floods  the  network.  We  also  expected  to 
see  very  little  improvement  when  changing  the  buffers  and  hold-queues.  The  fact  remained  fliat  if 
packets  are  process-switched,  there  is  a  finite  limit  to  speed  in  which  it  forwards  packets  successfully. 
We  will  discuss  more  about  these  issues  in  our  conclusions. 

The  following  two  sections  cover  the  result  sets  for  the  two  separate  environments  (point-to-point  and 
multipoint).  The  point-to-point  environment  results  were  used  to  gauge  the  expected  results  when  we 
combined  multiple  stations  broadcasting  in  the  network.  The  multipoint  configuration  better  represents 
the  tme  network  that  wiU  be  fielded  to  support  the  JADS  ETE  network. 

6.  Performance  Test  Results  (Point  to  Point  -  UDP  forwarding) 

Broadcaster  generating  400  packets  per  second  - 


Configuration 

Packets  Dropped 
(Broadcast  Side) 

Packets  Dropped 

(Logger  Side) 

PX-3toKX-3 

■;o  ■■■■ 

PX-3  to  APX 

■■■  O' 

Cisco  4000  to  PX-3 

0 

Cisco  7000  to  PX-3 

, 0. : 

Cisco  4000  to  Cisco  7000 

0 

0 

Cisco  7000  to  Cisco  4000 

■0 
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Broadcaster  generating  500  packets  per  second 


Configuration 

Packets  Dropped  Packets  Dropped 

(Broadcast  Side)  (Logger  Side) 

2366 

PX-3toAPX 

2366 

Cisco  4000  to  PX-3 

^  2366  ,  , 

Cisco  7000  to  PX-3 

2366 

Cisco  4000  to  Cisco  7000 

oVV\ 'V'. 

Cisco  7000  to  Cisco  4000 

-o; 

Broadcaster  generating  600  packets  per  second 


Configuration 

Packets  Dropped  Packets  Dropped 

(Broadcast  Side)  (Logger  Side) 

PX-3  to  PX-3  ,  , 

PX-3toAPX 

]  r  mn  ■ : 

ICiscp  4000  to  PX-3  ■ 

3927 

Ciscci  7000  to  PX-3 

,  0 

■  :  ,  3927  ■ 

Cisco  4000  to  Cisco  7000 

0 

Cisco  7000  to  Cisco  4000 

0 

Broadcaster  generating  700  packets  per  second 


Configuration 

Packets  Dropped  Packets  Dropped 

(Broadcast  Side)  (Logger  Side) 

PX-3  to  PX-3 

:  4722  : 

PX-3tt>APX 

,■■4722 

,  ^  \  s'-  ''  (  'P 

Cisco  4000  to  PX-3 

0 

:  4722^  « 

Cisco  7000  to  PX-3 

4722,,.  '' 

Cisco  40i00, to  Ci,sco  7000 

.  Cisco  7000  to  Cisco  4000 

'  ■'  ' .  P.:  ''"■  .■■■■4- 
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Broadcaster  generating  800  packets  per  second 


Configuration 

Packets  Dropped 
(Broadcast  Side) 

Packets  Dropped 

(Logger  Side) 

Hifiipiiwt? 

Cisco  4000  to  PX-3 

623 

5023,  ;  , 

Cisco  7000  to  PX-3 

'.5646'  ''"  "^ 

i  Cisco  4000  to  Cisco  7000 

■  ’  "623''';'- 

Cisco  7000  to  Cisco  4000 

0;  ' 

Broadcaster  generating  900  packets  per  second 

Configuration 

Packets  Dropped 

Packets  Dropped 

(Broadcast  Side) 

(Logger  Side) 

PX-3  to  PX-3 

0 

PX-3toAPX 

'  6239,;  '  " 

Cisco  4000  to  PX-3 

:^17 

,  4522;  ' 

^Cisco  7000  to  PX-3 

-6963' 

Cisco  4000  to  Cisco  7000 

Cisco  7000  to  Cisco  4000 

7.  Performance  Test  Results  (Multipoint  - 

UDP  Forwarding) 

Due  to  the  limited  resources  and  the  overall  intention  of  the  testing,  we  restricted  the  multipoint  tests  to 
the  PX  platfonns.  The  question  to  be  answered  was  whether  the  PX-3  would  respond  the  same  way 
as  the  point  to  point  test  but  with  various  interfaces  transmitting  broadcast  traffic.  With  two 
broadcasting  spoke  sites  and  a  single  logger  hub  site  we  got  the  following  results: 
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Broadcaster  generating  400  packets  per  second  (aggregate)  -  one  site  transmitting  at  200  pps  and  a 
second  site  transmitting  at  200  pps. 


Configuration 

Packets  Dropped 
(Broadcast  Side) 

Packets  Dropped 

(Logger  Side) 

PX-3  Hub /PX-3  Spokes  ’ 

.0  - 

PX-3  Hub/  APX  Spokes 

:.  0  „  . 

o’ 

Cisco  4000  to  PX-3 

Not  Tested 

Not  Teste  d 

Cisco  7000  to  PX-3 

Not  Tested 

Not  Tested 

Cisco  7000  to  Cisco  4000 

Not  Tested 

Not  Tested  - 

Broadcaster  generating  500  packets  per  second  (aggregate)  -  one  site  transmitting  at  300  pps  and  a 
second  site  transmitting  at  200  pps. 


Configuration 

Packets  Dropped  Packets  Dropped 

(Broadcast  Side)  (Logger  Side) 

PX-3  Hub  /  PX-3  Spokes 

.  0:^' 

//■;2366:, 

vPX-3  Hub/  APX  Spokes 

2366'i  .  ;• 

Cisco  4000  to  PX-3 

Not  Tested 

Not  Tested 

Cisco  7000  to  PX-3 

Not  Tested 

'  ,  Not  Tested  ;  '' 

Cisco  71)00  to  Cisco  4000  , 

Not  Tested 

Not  Tested 

As  expected,  the  aggregate  broadcast  traffic  at  the  hub  site  creates  the  same  results.  The  total  process¬ 
switching  capacity  for  the  PX  platform  is  limited  and  independent  of  the  interfaces  used. 

8.  Hybrid  Bridge/Router  Conflguration 

One  configuration  that  we  were  able  to  test  was  a  hybrid  biidge/router  configuration.  Our  testing  was 
restricted  to  the  unclassified  portion  of  the  network.  In  this  configuration  the  two  spoke  locations 
bridged  flie  serial  and  Ethernet  interfaces.  In  the  hub  location,  we  utilized  bridging  on  the  unclassified 
interfaces  and  routing  for  the  serial  interface  going  over  to  the  classified  portion  of  the  network.  Wifli 
this  configuration  we  were  able  to  successfully  pass  an  aggregate  of  600  pps  to  the  logger  off  the 
ethemet  interface  of  the  hub  node.  The  same  file  was  broadcast  from  two  different  bridge  segments,  so 
the  total  number  of  PDUs  broadcast  was  237 1 8  packets. 
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Broadcaster  generating  600  packets  per  second  (aggregate)  -  one  site  transmitting  at  300  pps  and  a 
second  site  transmitting  at  300  pps. 


Configuration 

Packets  Dropped  Packets  Dropped 

(Broadcast  Side)  (Logger  Side) 

PX-3  Hub /PX-3  Spokes  ' 

PX-3  Hub/ APX  Spokes 

Cisco  4000  to  PX-3 

Not  Tested 

Not  Tested  ^  x 

Cisco  7000  to  PX-3 

Not  Tested 

Not  Tested 

Cisco  4000  to  Cisco  7000 

Not  Tested 

Not  Tested 

Cisco  7000  to  Cisco  4000 

Not  Tested 

Not  Tested 

Broadcaster  generating  700  packets  per  second  (aggregate)  -  one  site  transmitting  at  300  pps  and  a 
second  site  transmitting  at  400  pps. 


Configuration 

Packets  Dropped 
(Broadcast  Side) 

Packets  Dropped 

(Logger  Side) 

PX-3  Hub  /  PX-3  Spokes 

2594  of 23718  sent 

PX-3  Hub/ APX  Spokes 

0 

2594  of 23718  sent 

Cisco  4000  to  PX-3 

Not  Tested 

Not  Tested 

'-V 

Not  Tested 

Cisco  4000  to  Cisco  7000 

Not  Tested 

Not  Tested 

*  Cisco  7000  to  Cisco  4000 

Not  Tested 

NotTested 

Further  testing  must  be  done  to  verify  the  effects  on  the  traffic  sent  over  the  serial  connection  to  the 

classified  logger. 

9.  Conclusions 

•  The  limitations  uncovered  during  the  testing  involved  the  level  of  process  switching  capacity  on  the 
PX-3,  the  Cisco  4000,  and  the  Cisco  7000. 

•  The  use  of  UDP  -  an  inherently  unreliable  transport  mechanism  -  is  not  always  a  suitable  choice  of 
transport  for  data  that  needs  a  high  level  of  rehabihty.  The  transmission  control  protocol  (TCP)  is 
better  suited  for  reliable  transport  since  it  uses  sequencing  and  acknowledgments,  but  at  a  cost  of 
increased  latency  -  which  was  not  tested.  Also,  the  use  of  multicasting  or  unicasting  would  take 
advantage  of  the  fast  switching  capability  of  all  the  routers  tested. 
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•  The  use  of  broadcast  based  networking  has  an  adverse  effect  on  the  network.  Routing  this  traffic 
adds  one  additional  layer  of  processing  (especially  when  the  broadcasts  are  process  switched)  and 
creates  multiple  copies  of  each  datagram  in  order  to  forward  it  to  multiple  network  subnets.  Thus, 
congesting  the  network  with  broadcast  traffic.  Since  the  key  application  relies  on  broadcasts,  we 
should  consider  flattening  the  network  and  use  bridging. 

•  There  were  definitive  “break  points”  where  the  processors  could  not  handle  an5Tnore  packets.  This 
is  hue  on  every  platform  tested. 

•  During  the  testing,  we  did  notice  that  there  were  drops  on  the  hold-queue,  missed  buffer  requests, 
and  fallbacks  on  the  interface  buffers.  To  remedy  this  we  added  to  the  hold-queue  length  and 
increased  the  number  of  permanent  big  buffers.  The  actual  number  of  successful  packets  sent  never 
rose  above  the  initial  ceilmg.  In  other  words,  the  addition  of  buffers  and  increasing  the  hold-queue 
did  not  affect,  in  any  way,  the  speed  at  which  the  processor  process-switched  the  packets.  This 
was  expected. 

•  It  is  our  best  judgment,  the  limitation  is  with  the  router’s  processor  handling  UDP  broadcasts.  With 
UDP  broadcast  traffic,  all  packets  are  process  switched.  With  unicast  and  multicast  traffic,  the 
router  is  capable  of  fast  switching  most  of  the  packets.  Routers  gain  efficiencies  when  they  are 
capable  of  caching  routes  for  packets. 

•  We  had  discussions  with  Technical  Assistance  Center  Staff  Engineers  fi:om  both  NET  and  Cisco 
Systems  over  the  last  two  weeks.  Engineers  firom  both  companies  stated  that  none  of  their  router 
platforms  have  ever  been  tested  to  find  what  are  the  limits  of  reliable  transport  of  UDP  packets. 

•  The  overall  configuration  relies  on  the  broadcaster.  If  the  networic  has  to  reliably  transport  UDP 
broadcasts  above  400  pps  (aggregate)  to  the  hub  node  to  be  logged  then  a  PX-3/APX  routed 
solution  will  not  suffice. 

10.  Recommendations 

The  initial  requirements  of  the  JADS  ETE  network  included  a  broadcaster  transmitting  100  packets  per 
second.  All  of  the  configurations  tested  will  satisfy  this  requirement.  Only  when  the  aggregate  packet 
load  on  the  PX-3  (using  UDP  forwarding)  exceeded  400  packets  per  second  was  there  a  concern  for 
losEdropped  packets.  With  bridging,  this  ceilmg  was  up  to  800  packets  per  second.  If  the  JADS  ETE 
network  is  to  continue  using  broadcasted  UDP  packets  with  a  small  number  of  sites,  bridging  would  be 
a  better  solution.  Options  and  limitations  ate  as  follows: 

Routing 

PX-3/APXs  -  400  pps  aggregate  limitation 

External  Cisco  4000  Routers  at  each  site  (serially  connected  via  HSD-2s)  -  up  to  700  pps 
aggregate  limitation;  higher  cost 
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Bridging 


PX-3/APXs  -  800  pps  aggregate  limitation 

Hybrid  Routing/Bridging 

PX-3/APXs  -  600  pps  aggregate  limitation 

Several  issues  have  to  be  addressed  (weighing  the  pros  and  cons): 

•  Broadcasting  at  lower  rates. 

•  Pro:  Limiting  the  speed  of  the  broadcasts  to  under  a  400  pps  aggregate  would  ensure  the  ability 
to  forward  all  of  the  UDP  traffic  through  the  network. 

•  Con:  The  impact  of  slower  rates  on  the  simulation  is  unknown. 

•  The  use  of  multicasting  in  the  fiiture. 

•  Pro:  The  use  of  multicasting  would  take  advantage  of  the  router’s  ability  to  fast  switch  the 
traffic.  The  router  only  has  to  process  switch  the  first  packet  to  find  the  route  and  will  stream 
the  following  data  along  the  same  route. 

•  Con:  Finding  a  suitable  data  logger  may  be  difficult  or  a  logger  would  have  to  be  written,  and 
the  impact  on  the  simulation  is  unknown. 

•  Bridging  the  entire  network. 

•  Pro:  The  use  of  bridging  would  increase  the  reliable  throughput  of  UDP  traffic  to 
approximately  800  pps.  However,  this  option  should  be  further  tested  on  the  entire  JADS  ETE 
network 

•  Con:  Speed  of  transmission  is  higher,  but  still  limited  to  800  pps.  Also,  it  may  be  difficult  to 
persuade  all  sites  to  be  part  of  the  same  subnet. 

•  The  cost  of  using  external  routers. 

•  Pro:  Different  router  platforms  have  different  processing  power.  There  are  other  platforms  that 
have  better  performance  in  forwarding  UDP  packets. 

•  Con:  There  are  tangible  limitations  where  the  processors  could  not  handle  process  switched 
traffic  -  regardless  of  platform.  Candidate  platforms  should  be  tested  for  this  application  before 
procurement.  Also,  cost  is  a  factor.  Costing  information  is  unavailable  at  this  time,  but  it  is  safe 
to  state  that  the  more  powerful  the  processor,  the  higher  the  cost. 
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APPENDIX  A.  ACRONYMS/DEFINITIONS 


ADS 

Advanced  Distributed  Simulation 

DIS 

Distributed  Interactive  Simulation 

DOD 

Department  of  Defense 

IP 

Internet  Protocol:  The  network  layer  for  the  TCP/IP  Protocol  Suite. 

JADS  JTF 

JOINT  ADVANCED  DISTRIBUTED  SIMULATION  JOINT  TEST  FORCE 

JSTARS 

Joint  Surveillance  Targeting  and  Attack  Radar  System 

LAN 

Local  Area  Network 

MAC 

Media  Access  Control:  The  lower  portion  of  the  datalink  layer. 

MAC-Layer  Bridge 

A  device  that  connects  two  or  more  similar  networks  in  a  way  that  is 
transparent  to  the  users  of  the  network  layer. 

OSI 

Open  Systems  Interconnection:  The  seven  layer  suite  of  protocols  to  be 
the  international  standard  computer  network  architecture. 

PDU 

Protocol  Data  Unit:  An  OSI  term  for  “packet.”  A  PDU  is  a  data  object 
exchanged  by  protocol  machines  (entities)  within  a  given  layer. 

PPS 

Packets  Per  Second 

T&E 

Test  and  Evaluation 

TCP 

Transmission  Control  Protocol:  An  Internet  standard  transport  protocol 
in  the  Internet  protocols  suite  for  reliable,  connection-oriented,  full-duplex 
streams. 

UDP 

USER  DATAGRAM  PROTOCOL:  An  Internet  standard  transport  protocol 
that  exchanges  datagrams  without  acknowledgments  or  guaranteed  delivery. 

WAN 

Wide  Area  Network 

A!1  Definitions  are  from  Guide  to  Networking  and  Internetworking  Terms.  Simoneau,  Paul,  ©  1993,  American  Group,  Cary  NC 
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APPENDIX  J 

Acronyms  and  Abbreviations 
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Appendix  J  -  Acronyms  and  Abbreviations 


AAR 

ACE 

ADS 

AFATDS 

ALQ-131 


ALSP 

ANIU 

AOI 

ARIES 

ARPA 

ASAS 

ATACMS 

ATWS 

BBS 

BIU 

bps 

C4I 

C4ISR 

CAMPS 

CBS 

CDP 

CEP 

CGS 

Cisco 

CPI 

CPU 

deg  or  ° 

DEAD 

DIS 

DISNIU 

DMA 

DoD 

DPDU 

DT 

DT&E 

DIED 


after  action  report/review 

analysis  and  control  element 

advanced  distributed  simulation 

Advanced  Field  ArtQleiy  Tactical  Data  System 

a  mature  self-protection  jammer  system;  an  electronic  countermeasures 

system  with  reprogrammable  processor  developed  by  Georgia  Tech  Research 

Institute 

aggregate  level  simulation  protocol 
air  network  interface  unit 
area  of  interest 

Advanced  Radar  Imaging  Emulation  System 
Advanced  Research  Projects  Agency 
All  Source  Analysis  System 
Army  Tactical  Missile  System 
Advanced  Technology  Work  Station 
Brigade  Battalion  Simulation 
bus  interface  unit 
bits  per  second 

command,  control,  communications,  computers  and  intelligence 

command,  control,  communications,  computers,  intelligence,  surveillance  and 

reconnaissance 

Compartmented  ASAS  (All  Source  Analysis  System)  Message  Processing 
System 

Corps  Battle  Simulation 
central  data  processor 
circular  error  probable 
common  ground  station 
Cisco  Systems,  Inc. 
coherent  processing  interval 
central  processing  unit 
degree 

digital  feature  analysis  data 

distributed  interactive  simulation 

distributed  interactive  simulation  network  interface  unit 

Defense  Mapping  Agency 

Department  of  Defense 

detonation  protocol  data  unit 

developmental  testing 

developmental  test  and  evaluation 

digital  terrain  elevation  data 
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EAGLE 

ECEF 

ES 

ESPDU 

ETE 

EW 

FDC 

Force 

FPDU 
ftor  ’ 

FTI 

FY 

GDI 

GIS 

GNIU 

GPC 

GRCA 

GSM 

HA 

hh 

HLA 

I&Q 

ID 

IDNX 

IP 

IRIS 

JAAWS 

JADS 

JanDIS 

JanPVD 

Janus 

JCM 

JFS 

Joint  STARS 

JT&E 

JTF 

km 

LAN 

LAOI 

LFP 


a  rule-based  tactical  simulation  developed  by  the  U.S.  Army  Training  and 
Doctrine  Command  (TRAC),  Leavenworth,  Kansas 
earth  centered  earth  fixed 
entity  state 

entity  state  protocol  data  unit 
End-To-End  Test 
electronic  warfare 
fire  direction  center 

a  menu  option  that  opens  the  Scenario  Forces  Editor  which  is  used  to  modify 
system  numbers,  aggregation,  and  task  force  assignments  for  a  Janus  scenario 
fire  protocol  data  unit 
feet 

fixed  target  indicator 
fiscal  year 

ground  data  terminal 
Geographical  Information  System 
ground  network  interface  unit 
general  purpose  computer 
ground  reference  coverage  area 
ground  station  module 
heterogeneous  aggregation 
hour 

high  level  architecture 

in-phase  and  quadrature  (radar  data) 

identification 

Integrated  Digital  Network  Exchange 
internet  protocol 

intemetted  range  interactive  simulations 
Janus  analyst  workstation 

joint  advanced  distributed  simulation  or  Joint  Advanced  Distributed 
Simulation,  Albuquerque,  New  Mexico 
Janus  Distributed  Interactive  Simulation 
Janus  Plan  View  Display 

interactive,  computer-based  simulation  of  combat  operations 
joint  conflict  model 

joint  feasibility  study  or  JADS  Joint  Feasibility  Study 
Joint  Surveillance  Target  Attack  Radar  System 
joint  test  &  evaluation 

joint  test  force  or  Joint  Test  Force,  Albuquerque,  New  Mexico 

kilometer 

local  area  network 

live  area  of  interest 

live  fly  phase 
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LSP 

LWX 

m 

M&IS 

MB 

Mbps 

MIL-STD 

mm 

MODSAF 

MOT&E 

MPDU 

MPSP 

ms 

MTI 

NIU 

OT 

OT&E 

Pd 

PDU 

PFA 

PSP 

rad 

RAM 

RCU 

RDO 

RDP 

RISS 

RPS 

RPSI 

RSB 

RSG 

RSR 

s  /  ss  /  sec 

S/N 

SAR 

SCDL 

SGI 

SIT 

SM&C 

SMO 

SPECTRUM 


linked  simulators  phase 

local  area  network/wide  area  network  exchange 
meter 

management  and  integration  software 
megabyte 

megabits  per  second  or  milhons  of  bits  per  second 
military  standard 
minute 

Modular  Semi- Automated  Forces 
multi-service  operational  test  and  evaluation 
message  protocol  data  unit 
modified  programmable  signal  processor 
millisecond 

moving  target  indicator 
network  interface  unit 
operational  test 
operational  test  and  evaluation 
probability  of  detection 
protocol  data  unit 
probability  of  false  alarm 
programmable  signal  processor 
radian 

reliability,  availability  and  maintainability;  random  access  memory 

radar  control  unit 

radar  data  operational 

radar  data  processor 

Radar  Image  Simulation  System 

radar  processor  simulation 

radar  processor  simulator  and  integrator 

radar  sensor  bus 

radar  sensor  group 

radar  service  request 

second 

signal-to-noise  ratio 
synthetic  aperture  radar 
surveillance  control  data  link 
Sihcon  Graphics,  Inc. 

System  Integration  Test 
system  management  and  control 
system  management  officer 

an  instrumentation  suite  used  to  measure  bandwidth  utilization 


sq  square 

STAGE  Scenario  Toolkit  and  Generation  Environment  -  scripted  simulation  by  Virtual 
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Prototypes,  Inc.,  that  is  used  to  build  complex  simulations  and  graphically 
define  interactive  tactical  scenarios 


STRICOM 

U.S.  Army  Simulation,  Training,  and  Instrumentation  Command 

SWA 

Southwest  Asia 

T&E 

test  and  evaluation 

T-1 

digital  carrier  used  to  transmit  a  formatted  digital  signal  at  1 .544  megabits  per 
second 

TAC 

target  analysis  cell 

TAFSM 

tactical  Army  fire  support  model 

TC 

target  classification 

TCAC 

Test  Control  and  Analysis  Center,  Albuquerque,  New  Mexico 

TCP 

transmission  control  protocol 

TCS 

topocentiic  coordinate  system 

TEXCOM 

U.S.  Army  Test  and  Experimentation  Command 

TRAC 

U.S.  Army  Training  and  Doctrine  Command  (TRADOC)  Analysis  Center 

TRADOC 

U.S.  Army  Training  and  Doctrine  Command 

u.s. 

United  States 

U-2R 

surveillance  aircraft 

UAV 

Unmanned  Aerial  Vehicle 

UDP 

user  datagram  protocol 

V&V 

verification  and  validation 

VDP 

VSTARS  data  packet 

VSTARS 

Virtual  Surveillance  Target  Attack  Radar  System 

W&A 

verification,  validation,  and  accreditation 

WAN 

wide  area  network 

WGS-84 

World  Geographic  System  1984 

WSMR 

White  Sands  Missile  Range 

XE.R. 

times  expected  rate 

XPATCHES 

E-8C  synthetic  aperture  radar  simulation  developed  by  Wright  Laboratory, 
Dayton,  Ohio,  and  Loral  Defense  Systems,  Goodyear,  Arizona 

